4 ms·

I agree with your comments generally, but I'm not sure I'm willing to say "it is all a matter of personal taste." Would you be opposed to a guideline that no m

I agree with your comments generally, but I'm not sure I'm willing to say "it is all a matter of personal taste." Would you be opposed to a guideline that no method should have a cyclomatic complexity above, say, 15?

sanj 19y ago
Would you rather have a single date format that switches based on an argument? Or create 20 little classes?
- michael_dorfman 19y ago
  The former, of course.
  - sanj 19y ago
    Then you've broken your self-imposed limit of a cyclomatic complexity of 15.
    - michael_dorfman 19y ago
      Which is why I suggested a "guideline", instead of a hard-and-fast rule. I'm not trying to remove programmer judgment from the equation; I'm just suggesting that there are some guiding principles that can be offered (and can be said to be more than simply matters of personal preference.)
mironathetin 19y ago
Personally I write my methods like I write text: one thought, one paragraph, one method. But: if a method is always used as an entity, meaning you don't need to reuse parts of its code elsewhere, there is no single reason split it only because it exceeds an arbitrary number of lines. There are reasons not to split it in that case. I know developers who write more than 15 lines of comments into their methods. That can be perfectly fine. My goal is to fit the code of one method on my screen without having to scroll. If its one thought, it should be comprehensible at one glance (Thats again personal taste, because it depends on the size of my screen ;o). If it has to be longer, its not a problem of metrics. Its more a problem that the design is not clear enough and the things to do are too complex.
- michael_dorfman 19y ago
  I agree. I'm not suggesting splitting a method that exceeds an arbitrary number of lines. Instead, I'm asking about the cyclomatic complexity (http://en.wikipedia.org/wiki/Cyclomatic_complexity http://en.wikipedia.org/wiki/Cyclomatic_complexity) My point being that while the original article was quite ridiculously reductionist, it should be possible to have some concrete metrics that serve as good guidelines (and which naturally could be superceded by programmer judgment on occasion.)

sanj 19y ago

Would you rather have a single date format that switches based on an argument? Or create 20 little classes?

michael_dorfman 19y ago
The former, of course.
- sanj 19y ago
  Then you've broken your self-imposed limit of a cyclomatic complexity of 15.
  - michael_dorfman 19y ago
    Which is why I suggested a "guideline", instead of a hard-and-fast rule. I'm not trying to remove programmer judgment from the equation; I'm just suggesting that there are some guiding principles that can be offered (and can be said to be more than simply matters of personal preference.)

mironathetin 19y ago

Personally I write my methods like I write text: one thought, one paragraph, one method. But: if a method is always used as an entity, meaning you don't need to reuse parts of its code elsewhere, there is no single reason split it only because it exceeds an arbitrary number of lines. There are reasons not to split it in that case. I know developers who write more than 15 lines of comments into their methods. That can be perfectly fine. My goal is to fit the code of one method on my screen without having to scroll. If its one thought, it should be comprehensible at one glance (Thats again personal taste, because it depends on the size of my screen ;o). If it has to be longer, its not a problem of metrics. Its more a problem that the design is not clear enough and the things to do are too complex.

michael_dorfman 19y ago
I agree. I'm not suggesting splitting a method that exceeds an arbitrary number of lines. Instead, I'm asking about the cyclomatic complexity (http://en.wikipedia.org/wiki/Cyclomatic_complexity http://en.wikipedia.org/wiki/Cyclomatic_complexity) My point being that while the original article was quite ridiculously reductionist, it should be possible to have some concrete metrics that serve as good guidelines (and which naturally could be superceded by programmer judgment on occasion.)