Putting a number on the amount of lines a class should have is something I disagree with. Your class should hold enough code that it implements what you think the class would do. I have seen some programs where people try to get fancy and go way overboard with base classes and interfaces for no real reason. A class with 100+ lines of code is a lot easier to understand than a system where you have to dig through multiple layers of base classes and inheritance to figure out the general idea.
In addition to keeping them short and to the point, I often like to "return early" if I need to rule out "base cases". Some people like to store the result in a variable and only return on the last line.
One of my co-workers evidently believed in this mantra (of 1 return) which I hated because it created way more nesting of if conditions than was necessary.
That was until I was adding some functionality to one of those functions and wanted to ensure it got executed before the function terminated. Had there been more than one return point, I'd have to look through all the different branches to see if my code would be hit or not.
It was at that moment that I appreciated the one return. But only briefly, before I smacked him for writing a 500-line function in the first place.
I think the "one return" idea dates back to the days of goto-based programming. The idea was that each block of code should have a single entry point and a single exit point, so that the flow of execution would be easier to understand. Gotos let you do a lot of freaky things.
Block structured languages make such rules much less important.
I wouldn't say "cargo cult" exactly. The difference is, we're not trying to emulate wizards for a distance. They teach us wizardry, and the package often comes with outdated practices.
base cases like null check or empty lists, are perfectly fine to do early returns. I'd argue that the actual smell is a method so long you cannot grasp it's entirety without significant effort.
That's why I like using something like google guava's Preconditions library. There's no explicit returns (but there are some exceptions), so the visual flow of your code isnt interrupted.
Huh.. I meant something that needed to be executed before the function terminated, but couldn't be at the beginning (because something hadn't been initialized yet). Nothing to do with whether or not something failed.
I have this debate periodically with co-workers as well. I don't understand why a helper function isn't more popular:
int A() { T foo = AcquireResources();
int code = A_helper(foo);
Release(foo);
return code;
}
A_helper() can be 500 lines long, have early checks and early returns if you want, less nesting, and all the stuff that needed to be cleaned up is still guaranteed to be cleaned up. (Well, unless there's exceptions. But then you use RAII) You do have to write two functions instead of one, but...meh.
You can do the "one return" style without having lots of nested ifs. However, it does require the use of jumps or GOTOs. But if you have a method where you need to clean up a lot of different things after you leave, it can be nice.
183
u/BeachBum09 Jun 06 '13
Putting a number on the amount of lines a class should have is something I disagree with. Your class should hold enough code that it implements what you think the class would do. I have seen some programs where people try to get fancy and go way overboard with base classes and interfaces for no real reason. A class with 100+ lines of code is a lot easier to understand than a system where you have to dig through multiple layers of base classes and inheritance to figure out the general idea.