371–380 of 601 posts
Earlier quoted context omitted.
>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...
Eh, all things equal, the less the number of lines the more readable.
I find a compromise is best. First, do the simple checks "Oh, this function returns an empty set if one of its parameters is null? Do that". Then go into the main method body. In the main method body, I want to see elses on ifs. I'm okay with putting a return in each branch of the if/else, but what I find bad is when the main body is ``` if(foo) { doLotsOfStufff(); return myResult; } return bar; ``` That pattern I ca…
I also disagree with needing a comment, which is why I think not having an else in the first example is great. Having a return statement at the end of a function is obvious, and then all you have to do is scan upwards to find other return tokens. Especially because the final return need not be an error state.
Earlier quoted context omitted.
python fans are going like "what are braces?"
The irony is that Python actually has open-braces, but they're spelled ":" instead of "{". And the syntax effectively enforces K&R style. When I write Python I end every block with a "pass" statement so that emacs can auto-indent my code properly. The "pass" statement thus effectively becomes a close-brace. It drives Pythonistas into conniptions, but I never have to worry about reverse-engineering a block of code to…
I guess I'm the minority here, I prefer "if else" with the happy path inside the if. Returning early gives me mental overhead of keeping the "elses" on my head, and doing it in Scala makes the code look more verbose.
I don't think you're in the minority. Whenever possible the happy path should be inside the if. The article seems to imply otherwise but on re-read I think he is just building the case for putting the simple, quick pre-condition type handling up front which generally removes the need for the if/then (which I agree with). For complex methods with branching logic you want prominently displayed, you'd end up with: def m…
So break early.
"removing a whole line and more braces" - this is really fighting the wrong enemy. Code should be written in a way it is more readable, not shorter.
Ceteris paribus, shorter code always is more readable. It's the only guideline I've found true regardless of programming language or environment. Shorter is better.
I often find inelegant, yet straightforward solutions are generally better options than dense, mathematically pure solutions, simply because inelegant code usually relies on fewer assumptions. Noting that code rarely/never evolves the way we expect it to, apply Occam's razor and strike a balance.
Earlier quoted context omitted.
If the return value is important: if (err) return void handleError(err) And in non-promise-based async JS, the return value is almost always lost/useless anyway so `return x` has no effect, might as well repurpose `return` for short-circuiting.
I don't think throwing void at people is generally going to make anything clearer.
Earlier quoted context omitted.
Here's an extreme, yet very real example: mandatory Doxygen comments on accessors: /** * Get the foo * * @return the foo */ int getFoo(); /** * Get the bar * * @return the bar */ float getBar(); /** * Set the foo * * @param foo the foo */ void setFoo(int foo); /** * Set the bar * * @param bar the bar */ void setBar(float bar); Compare with what any sane project would do: int getFoo(); float getBar(); void setFoo(int…
Meh. It's noise but what's the harm? It was generated by an IDE so nobody had to physically type that. And usually no developer will be dwelling on this object or this area of the object. It just sits there doing no harm to anyone. >LOC is more valid as a metric than most care to admit. It's not.
I'll repeat my current gut feeling. Intrinsic measures of software quality are terrible as guides for how to write code. They are decent at predicting quality, but are not usable in a prescriptive way to write quality code.
Earlier quoted context omitted.
The earlier version is clearly better and more clear, but presumes a language where if is an expression (and the actual return keyword isn't required, though “return if ...” is nearly as good.) But if you are using a more imperative language where “if” is a statement, I think the merits of early return vs. use of an else clause are more balanced in this case.
In C style languages you have the ?: operator though, which is basically if as an expression.
return (a>=b) ? a : b
Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…
> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.