4 ms·
I am a reformed indentaholic. Now I adore early returns and use them often. If you follow the first cardinal rule of OOP, keep methods short, then early returns
by snorkel 18y ago
I am a reformed indentaholic. Now I adore early returns and use them often. If you follow the first cardinal rule of OOP, keep methods short, then early returns are easy to spot.
This kind of short-sighted nesting annoys me:
function foo(bar) {
if (bar == 1) {
doThis();
} else {
var x = doSomething();
if (x == 2) {
doSomethingElse();
} else {
var y = doThat();
// ... more code here ...
for (var m=0; m<y; m++) {
doBoo(m);
}
}
}
}
Yuck! I much prefer:
function foo(bar) {
if (bar == 1) {
doThis();
return;
}
var x = doSomething();
if (x == 2) {
doSomethingElse();
return;
}
var y = doThat();
// ... more code here ...
for (var m=0; m<y; m++) {
doBoo(m);
}
return;
}
The difference here is not drastic in this short example but in functions with 50+ lines of code it's very clear.
The average person's short term memory is only 5 - 7 items deep. 3 of those slots are already occupied with what they are doing, so you have 2 slots left, maybe 4 slots if they've had their coffee and are really paying attention. Every time you make a code indent, whether it be a loop or nested condition, then you're asking the reader to remember that context switch. Once you have indenting more than two tabs deep then you're in hazy territory where the reader is unlikely to remember all of the conditions that lead to those lines of code being executed.
- jcl 18y agoOne other heuristic I follow that's not mentioned in the essay is: If one branch of an "if" statement is much shorter than the other, change the condition so that you can put the short branch first. My reasoning is also involves memory: While the reader is reading the first branch, he needs to hold the possibility of an "else" branch in his head, along with the condition. By minimizing the length of the first branch, you minimize the amount of time he needs to remember this.
- scott_s 18y agoI disagree. I think it depends on context. Generally, one branch is the more common case, and I prefer to put that one first. It's the main flow of the code.
- queensnake 18y agoYes but, say you've got a longish chunk of code with several error conditions; you come across an 'else' after a lot of closing braces. What the heck does it match with? What other error conditions need handling and got forgotten in the forward rush of common cases? Error handling is easy to forget; the common case remembers /itself/ you might say, and can be put off for a moment while you get the clutter out of the way. My MO, anyway.
- scott_s 18y agoI stress the common case for the same reason that when I construct sentences, I try to put the main point up front, and save the side comments for later. Example: "I ran into Bob while walking to the store." "While walking to the store, I ran into Bob." The point I'm trying to get across, in this case, is that I ran into Bob. I try to do the same with code.