4 ms·
This is all a matter of personal taste. With small methods you indeed make code hard to read and harder to debug. Plus you generate method calling overhead (ye
by mironathetin 18y ago
This is all a matter of personal taste.
With small methods you indeed make code hard to read and harder to debug. Plus you generate method calling overhead (yes I know, a smart compiler will inline - but if thats true, you can inline yourself). Combine atomic methods with a wealth of design pattern, and your code may become absolutely unmaintainable (all in the name of pure object orientation and better maintainablility).
If - else chains cannot be avoided with small methods (one for if and one for else). You just move the if else to the point, where the decision for the one or the other methods has to be made. A smart replacement for if else chains is switch.
But as I said, please no flamewar. I think the best you can do is to leave every programmer with his own style. That will make him most productive. All these stupid rules come from non programming managers, who want one style throughout their whole codebase, because they believe this makes every programmer easily replacable. This is no developers interest (and its not true anyway).
Pure oo style leads to some very dangerous constructs. In my experience, the true oo scholars often produce slow code, thats a memory sink (ever created a new object in a loop?).
Like with patterns, it needs a lot of experience to know, when to use them and when to avoid them. These truly simple rules, are in my opinion made for beginners (and I tend to say also: by beginners).
What matters most, is a clear style, comments, well chosen variable names. Everything that makes your code easier to understand - and that mainly for you, the author, because if someone has to maintain your code, he very likely will rewrite it. And that can be smart, because most of the time its the faster way.
- michael_dorfman 18y agoI 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 18y agoWould you rather have a single date format that switches based on an argument? Or create 20 little classes?
- michael_dorfman 18y agoThe former, of course.
- sanj 18y agoThen you've broken your self-imposed limit of a cyclomatic complexity of 15.
- michael_dorfman 18y agoWhich 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 18y agoPersonally 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.)