4 ms·
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 t
by mironathetin 18y 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 18y agoI 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.)