4 ms·

Yeah, there's a few things here that set me on-edge. For one, early returns means you have to go poking around for the returns. That highly-indented style is

Yeah, there's a few things here that set me on-edge. For one, early returns means you have to go poking around for the returns. That highly-indented style is a much clearer "bad code smell" that makes it easier to clean up the routine. And their "reduce curly braces" is just SCREAMINGLY awful. If you have a one-line block, you STILL want curly braces around it. The eye just loves to skim over this mistake: if (condition) i++; applyTaxes(order);

dangoldin 18y ago
I agree with you. I dislike returns scattered throughout a single method. Makes tracking them a bit difficult.
- cstejerean 18y ago
  does your editor not highlight returns properly?
  - dangoldin 18y ago
    Most of my editors do but I end up doing a lot of work SSHed from other computers without windows so I end up doing a good amount of work in raw text files. Also, it's easier for me to process a single return line than to take a look at the logic behind each of the other returns. If I end up returning an undef at the beginning of a function and then edit it a few months later I may just skip that step and not see where that case is being handled. It just seems a better way to structure my code, for me at least.
    - cstejerean 18y ago
      I do 99% of my work in a terminal and usually over ssh. that's why I use Emacs. Since you use a single return statement I'm assuming you keep track of the value to return by assigning it to a variable. How is keeping track of multiple assignments to the variable you will return easier than keeping track of multiple return statements? I've always found it easier to keep track of return statements since they're highlighted.
      - dangoldin 18y ago
        Yea I would prefer to use Emacs but I don't get access to that all the time. Thus my returns don't always get highlighted so it's as if I am using a basic text editor. In addition, I tend to read code from the bottom up (literally), so I end up tracing that return value upwards through the code. Also, having some simple branching let's me quickly identify what each block of code is doing. Clearly there is not one way to do things and there are times where it's significantly easier to just return in the beginning but for more advanced cases I like having variables keep track. Also, when there are many steps involved in the computation, it's easier to keep track of the individual pieces and then combine them at the very end than have that logic dispersed throughout the function. I have also recently started favoring returning hashes so in case I ever need to add some additional results, backwards compatibility is preserved and I only need to work on one return statement.
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 ago
  One 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 ago
    I 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.
jrockway 18y ago
Does this really throw people off? I see code like this from time to time, and my brain mentally ends that first "if" statement right at the ; after i++. It even did when I was reading the above example.
- jcl 18y ago
  Yes, it throws people off, especially when it's buried in the middle of other code.

dangoldin 18y ago

I agree with you. I dislike returns scattered throughout a single method. Makes tracking them a bit difficult.

cstejerean 18y ago
does your editor not highlight returns properly?
- dangoldin 18y ago
  Most of my editors do but I end up doing a lot of work SSHed from other computers without windows so I end up doing a good amount of work in raw text files. Also, it's easier for me to process a single return line than to take a look at the logic behind each of the other returns. If I end up returning an undef at the beginning of a function and then edit it a few months later I may just skip that step and not see where that case is being handled. It just seems a better way to structure my code, for me at least.
  - cstejerean 18y ago
    I do 99% of my work in a terminal and usually over ssh. that's why I use Emacs. Since you use a single return statement I'm assuming you keep track of the value to return by assigning it to a variable. How is keeping track of multiple assignments to the variable you will return easier than keeping track of multiple return statements? I've always found it easier to keep track of return statements since they're highlighted.
    - dangoldin 18y ago
      Yea I would prefer to use Emacs but I don't get access to that all the time. Thus my returns don't always get highlighted so it's as if I am using a basic text editor. In addition, I tend to read code from the bottom up (literally), so I end up tracing that return value upwards through the code. Also, having some simple branching let's me quickly identify what each block of code is doing. Clearly there is not one way to do things and there are times where it's significantly easier to just return in the beginning but for more advanced cases I like having variables keep track. Also, when there are many steps involved in the computation, it's easier to keep track of the individual pieces and then combine them at the very end than have that logic dispersed throughout the function. I have also recently started favoring returning hashes so in case I ever need to add some additional results, backwards compatibility is preserved and I only need to work on one return statement.

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 ago
One 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 ago
  I 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.

jrockway 18y ago

Does this really throw people off? I see code like this from time to time, and my brain mentally ends that first "if" statement right at the ; after i++. It even did when I was reading the above example.

jcl 18y ago
Yes, it throws people off, especially when it's buried in the middle of other code.