Earlier quoted context omitted.
python fans are going like "what are braces?"
Tell them braces are visual indicators of blocks of logic, enabling reasoning more easily on a multi-statement level.
Lambdas shouldn't be more than one line anyway.
Avoid Else, Return Early (2013)
441–450 of 601 posts
Re: Avoid Else, Return Early (2013)
#442I agree with everything apart having if and return statement in the same line. It makes code really difficult to read.
In addition, I also like is to avoid if/else when returning bool values:
if (a > b) {
return true;
} else {
return false;
}
return (a > b);Re: Avoid Else, Return Early (2013)
#443In Common Lisp the syntax for early return is so ugly (```(return-from function-name result)```) that I use it very rarely. In general, it seems that in the languages that use implicit return (Lisps, Haskell, Rust?) having an early return is discouraged by design.
In the rare case a return is needed, I prefer to put a nil block and a simple return, e.g. (return value). The nil block stands out and warns about the presence of a return. It also helps that all iteration constructs (do-*) have an implicit nil block.
Re: Avoid Else, Return Early (2013)
#444Earlier quoted context omitted.
> The thing the brace tells you is already told by the indentation Which is true, and of course begs the question: why do you even need the braces?
1) I frequently tell my diffs to ignore whitespace so I can see my structural changes without getting drowned in a sea of indentation changes when introducing new scopes. Not viable when diffing python. 2) I semi-frequently make indentation mistakes when resolving merge conflicts. In braced languages this is fixed by an autoreformat. In unbraced languages, I have to take a lot more care with merging, lest I end up in…
In this specific case
if (a) {
print(a)
}
Could just be if (a) print (a)
Except in perl, where it's
print (a) if (a)
if (a) { print(a) }
Re: Avoid Else, Return Early (2013)
#445Earlier quoted context omitted.
> 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.
Totally disagree with you.... it's funny though that I read LOC as "level of complexity" not "lines of code". I've been writing code for 30 years and I think it's jarring when the braces are on the next line, so much easier for me to parse that when it's on the same line. But everyone is entitled to their own opinion.
I remember in my programming classes at school my teacher was always like: guys!there is space on the right! Use it!
PS: he coded at Hercules the graphic cards back in the day before he got into teaching.
Re: Avoid Else, Return Early (2013)
#446Earlier quoted context omitted.
> Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.
The problem with this is maintaining comments. If you are using a compiled language or even linting, code that is part of the codebased is checked by a machine at least in a cursory way and the code that is there is what runs. The comments are not guaranteed in any way to pertain to the code that is in the repo and there is not a way for a computer to check the meaning of the comment to make sure that it was updated…
That's what code reviews are for, to help developers check each other for things that cannot be automatically linted.
Re: Avoid Else, Return Early (2013)
#447In case guard-clause is used for input-validation, how about extracting the arguments to a class of which constructor prevents instantiation of a class with invalid input, and pass that to the function?
Re: Avoid Else, Return Early (2013)
#448Earlier quoted context omitted.
> Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.
Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.
For an alternate perspective you might find persuasive, I recommend you read through the following slide deck: http://www.sqlite.org/talks/wroclaw-20090310.pdf. (Relevant part starts on slide 80, but I recommend you start from the beginning for full context.)
Re: Avoid Else, Return Early (2013)
#449"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.
Shorter code may or may not make things more readable. If brevity was the key to readability, we'd all be minifying all code we write to make it more readable.
Readability is about clarity of intent and function, as well as sensible structure. Sometimes that means writing slightly more code with more expressive naming so that the code is easier to follow. Sometimes that means using a given language's shortcuts to condense things down.
Re: Avoid Else, Return Early (2013)
#450This is why I'm so sad that Elixir doesn't have a return statement.
But Elixir 'does' have early returns, they are known as `Guards` as a language construct.