201–210 of 601 posts
This also works well with a C++ `defer` helper. #define CONCAT_LITERAL(x, y) x ## y #define CONCAT(x, y) CONCAT_LITERAL(x, y) template struct DeferWrapper { F f; DeferWrapper(F f) : f(f) {} ~DeferWrapper() { f(); } }; template DeferWrapper deferWrapper(F f) { return DeferWrapper (f); } #define defer(code) auto CONCAT(_defer_, __COUNTER__) = deferWrapper([&]() code) Example of usage: { Foo *foo; if (initializeFoo()) {…
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 you get joy deleting large swaths of code. This is the true sign of a programmer's transcendence. Specifically the irrational joy of seeing net negative LOC diffs. It's not about how much you can add. It's about how much you can remove without sacrificing correctness, functionality, and readability.
"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.
Exactly. This led to the famous OSX double goto bug [0] if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; ... other checks ... fail: ... buffer frees (cleanups) ... return err; [0] https://www.dwheeler.com/essays/apple-goto-fail.html
I think there's a lot of value to returning early out of functions when you hit an error condition. There's not much reason to go further if you're just completely hosed. (e.g. malformed arguments). However, I don't think that coders should shy away from built-up result values for return. It makes the code more friendly to things like copying (I can feel the boos and hisses now), block restructuring, #ifdef'ing (or s…
Earlier 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.
I am not advocating for the opposite but having return statements in the middle of the code does have its drawbacks. In many instances it makes the code less easy to read. For instance when I write:
If (x) {
Return y;
}
Return z;
Anyways. All in all, just optimize your code for what makes sense and avoid general advice on code formatting.
Earlier quoted context omitted.
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've done a number of informal tests on friends and family over the years regarding brace placement, and it's always been the same: For someone with NO experience programming (i.e. looking at what to them seems like a bunch of gobbletygoop - and what's a "text editor"?), adjacent braces make it appear more readable than same-line braces. It's only people who cut their teeth on adjacent bracing that find it more reada…
I've seen both, and the reduction in vertical whitespace matters more to me than the readability to an untrained individual.
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…
For whatever it's worth, I insisted on single return for a long time when I was an intermediate programmer. 30 years in, I strongly prefer return early (as well as continue early in loops) and I cannot go back. The immensely reduced indentation is marvelous. Having that 'happy path' consolidated is more readable.