+ Control Coupling is a kind of duplication, because the calling method already knows which path should be taken. +
++ Control Coupling reduces the code's flexibility by creating a dependency between the caller and + callee: any change to the possible values of the controlling parameter must be reflected on both + sides of the call. A Control Couple also revmethoeals a loss of simplicity: the called method probably + has more than one responsibility, because it includes at least two different code paths. +
+ ]]> ++ Control Coupling is a kind of duplication, because the calling method already knows which path should be taken. +
++ Control Coupling reduces the code's flexibility by creating a dependency between the caller and + callee: any change to the possible values of the controlling parameter must be reflected on both + sides of the call. A Control Couple also revmethoeals a loss of simplicity: the called method probably + has more than one responsibility, because it includes at least two different code paths. +
+ ]]> ++ Control Coupling is a kind of duplication, because the calling method already knows which path should be taken. +
++ Control Coupling reduces the code's flexibility by creating a dependency between the caller and + callee: any change to the possible values of the controlling parameter must be reflected on both + sides of the call. A Control Couple also revmethoeals a loss of simplicity: the called method probably + has more than one responsibility, because it includes at least two different code paths. +
+ ]]> ++ The recurrence of the items often means there is duplicate code spread around to handle them. + There may be an abstraction missing from the code, making the system harder to understand. +
+ ]]> +A simple example would be the following method, which "belongs" on the Item class and not on the Cart class:
+class Cart
+ def price
+ @item.price + @item.tax
+ end
+end
+ + Feature Envy reduces the code's ability to communicate intent: code that "belongs" on one class but which + is located in another can be hard to find, and may upset the "System of Names" in the host class. +
++ Feature Envy also affects the design's flexibility: A code fragment that is in the wrong class creates + couplings that may not be natural within the application’s domain, and creates a loss of cohesion in the + unwilling host class. +
++ Feature Envy often arises because it must manipulate other objects (usually its arguments) to get them + into a useful form, and one force preventing them (the arguments) doing this themselves is that the common + knowledge lives outside the arguments, or the arguments are of too basic a type to justify extending that + type. Therefore there must be something which 'knows' about the contents or purposes of the arguments. + That thing would have to be more than just a basic type, because the basic types are either containers + which don't know about their contents, or they are single objects which can't capture their relationship + with their fellows of the same type. So, this thing with the extra knowledge should be reified into a class, + and the utility method will most likely belong there. +
+ ]]> ++ A Utility Function reduces the code's ability to communicate intent: code that "belongs" on one + class but which is located in another can be hard to find, and may upset the "System of Names" in + the host class. A Utility Function also affects the design's flexibility: A code fragment that + is in the wrong class creates couplings that may not be natural within the application's domain, + and creates a loss of cohesion in the unwilling host class. +
++ A Utility Function often arises because it must manipulate other objects (usually its arguments) to + get them into a useful form, and one force preventing them (the arguments) doing this themselves + is that the common knowledge lives outside the arguments, or the arguments are of too basic a type + to justify extending that type. Therefore there must be something which 'knows' about the contents + or purposes of the arguments. That thing would have to be more than just a basic type, because the + basic types are either containers which don’t know about their contents, or they are single objects + which can't capture their relationship with their fellows of the same type. So, this thing with the + extra knowledge should be reified into a class, and the utility method will most likely belong there. +
+ ]]> ++ Conditional code is hard to read and understand, because the reader must hold more state in his head. + When the same value is tested in multiple places throughout an application, any change to the set of + possible values will require many methods and classes to change. Tests for the type of an object may + indicate that the abstraction represented by that type is not completely defined (or understood). +
+ ]]> +if,
+ else, case, when, for, while,
+ until, begin, rescue — but it doesn't count the control
+ structure itself.
+
+ + So the following method would score +6 in Reek's statement-counting algorithm: +
+
+def parse(arg, argv, &error)
+ if !(val = arg) and (argv.empty? or /\A-/ =~ (val = argv[0]))
+ return nil, block, nil # +1
+ end
+ opt = (val = parse_arg(val, &error))[1] # +2
+ val = conv_arg(*val) # +3
+ if opt and !arg
+ argv.shift # +4
+ else
+ val[0] = nil # +5
+ end
+ val # +6
+end
+
+ (You might argue that the two assigments within the first if should count
+ as statements, and that perhaps the nested assignment should count as +2. If you do,
+ please feel free to vote up ticket #32.)
+
+ Poor names make it hard for the reader to build a mental picture of what's going on in the code. + They can also be mis-interpreted; and they hurt the flow of reading, because the reader must + slow down to interpret the names. +
+ ]]> ++ Poor names make it hard for the reader to build a mental picture of what's going on in the code. + They can also be mis-interpreted; and they hurt the flow of reading, because the reader must + slow down to interpret the names. +
+ ]]> ++ Poor names make it hard for the reader to build a mental picture of what's going on in the code. + They can also be mis-interpreted; and they hurt the flow of reading, because the reader must + slow down to interpret the names. +
+ ]]> ++ Poor names make it hard for the reader to build a mental picture of what's going on in the code. + They can also be mis-interpreted; and they hurt the flow of reading, because the reader must + slow down to interpret the names. +
+ ]]> ++ Poor names make it hard for the reader to build a mental picture of what's going on in the code. + They can also be mis-interpreted; and they hurt the flow of reading, because the reader must + slow down to interpret the names. +
+ ]]> ++ Having unused parameters in a method is code smell because leaving dead code in a method + can never improve the method and it makes the code confusing to read. +
+ ]]> +