Timeline for Are long methods always bad?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 16, 2012 at 23:34 | comment | added | cgmb | @JimmyHoffa toString is not a good example. There are many ways to represent a variable in a string. If the 'toString' name were all that was necessary to understand what it was doing, we wouldn't have questions like this: stackoverflow.com/q/8492449/331041 | |
| Oct 16, 2012 at 11:41 | history | made wiki | Post Made Community Wiki by Aniket Inge | ||
| Oct 16, 2012 at 9:34 | comment | added | K.L. | On a side note, having a method that needs n parameters is also a code smell and indicates that the method may do more than one thing. Same goes for having a method thats hard to name. And if it really needs all those parameters, they usually are a part of a bigger concept, that can and should be enclosed in a class of its own. Of course, we could come up with an example thats better off not using this rule - my point is that if you see such a method, investigate it throughly, it probably is bad in some way. | |
| Oct 16, 2012 at 9:01 | comment | added | Svish | I find splitting up long methods like these is only useful if you can actually pull out logical parts that make sense and that can be fairly on their own. In other words, if what I pull out is difficult to name and define or have to take almost every single variable I have defined as parameters, then it's probably just as readable to keep the code in the long method. However if the method is easy to name and define, it only needs a couple of parameters to do it's work and maybe even can be made static, then it can make sense. | |
| Oct 15, 2012 at 22:59 | comment | added | Jimmy Hoffa |
@wobbily_col You say that having to jump around too much to understand the code with many methods is confusing, I think the missing point here is on the importance of naming. If a method is well named, you do not need to look at it to find out what it's doing, the calling method should be completely comprehensible without any underlying knowledge of what the methods it calls are doing, for instance have you ever used someVar.toString() and felt you needed to see the code of toString to know what it is doing? You just read right past it because of good method naming.
|
|
| Oct 15, 2012 at 17:18 | comment | added | Daniel B | @wobbily_col BTW, if you're looking for a well-written text which goes through the rationale of having shorter methods, read the first few chapters of Clean Code, which does a pretty good job of the explanation. | |
| Oct 15, 2012 at 16:27 | comment | added | Daniel B | @wobbily_col I think part of it is quite subjective, that's why I've tried to keep it as objective as possible. Personally, I like to keep everything short - methods, classes, etc. If a method gets too big, I refactor, and if a class gets too big, I refactor. Some might argue that this leads to too much "jumping around", but having a project well structured combats a lot of that. If a problem needs 5000 lines of code to solve, it deserves it's own little namespace with multiple classes. | |
| Oct 15, 2012 at 16:03 | comment | added | wobbily_col | OK looking at the list above: readability I would say from past experience is increased by having the method longer, containing lots of comments, and well formatted, rather than having to jump about the code from method to methods Though this is probably quite subjective. I don't expect the parts of the code to be reused. Most of the reuse of the code is achieved from inheritance at the moment. | |
| Oct 15, 2012 at 14:58 | history | edited | Daniel B | CC BY-SA 3.0 |
added 512 characters in body
|
| Oct 15, 2012 at 14:58 | comment | added | Jimmy Hoffa | +1 for disavowing the always part of the question and focusing on the meat: Whether or not long methods are bad. I think the OP is looking for justification as though his scenario is an edge case, though usually when I hear people explain away their bad practices as necessary for the uncommon scenario, it's just because they didn't try very hard to use good practices. The uncommon scenarios are truly very uncommon, long methods are sadly however quite common. | |
| Oct 15, 2012 at 14:40 | comment | added | Phil | "I'm fairly certain that this problem could be trivially fixed by some form of passing by reference" - or it could potentially be fixed by creating a separate class to encapsulate the loop itself. I generally prefer this to passing by reference, but I'm not a Python expert either. | |
| Oct 15, 2012 at 13:47 | history | edited | Daniel B | CC BY-SA 3.0 |
added 108 characters in body
|
| Oct 15, 2012 at 13:01 | history | edited | Daniel B | CC BY-SA 3.0 |
added 175 characters in body
|
| Oct 15, 2012 at 12:54 | history | answered | Daniel B | CC BY-SA 3.0 |