461–470 of 601 posts
Earlier quoted context omitted.
Can't that be taught as well? (both rules, and exceptions to rules?)
Sure. But as a novice youd should adhere to rules. As you gain experience you learn when to break them.
I think the "rule" should be "exit early", and the exception "multi-indent exit later".
Earlier quoted context omitted.
Emacs autoindent to the rescue: void MyLongMethodName(SomeLongParamType param1, SomeOtherLongParamType param2, YetAnotherLongParamType param3) { if (longContrivedVariableName1 == longContrivedVariableName2 && longContrivedVariableName1 != longContrivedVariableName3) { // do stuff } }
IME the more complex your code formatting, the less likely people are to do it, especially after your code has been touched by dozens of different people with a dozen different editors.
Earlier quoted context omitted.
> single exit point rule, What makes it a "rule" or as sometimes said, a "law"? It's just a style, and it has pros and cons, cases where it helps, and cases where it hinders.
It's interesting when style becomes rules, the years goes by and no one challenge the "best practice", languages and frameworks might change, but the rules stay, for no good reason. So yeh, why only one return !?
FWIW, I would start making plans to leave a company where any significant amount of my colleagues followed rules like this without challenging them or being able to articulate their rationale.
Earlier quoted context omitted.
Wrong. You need to exit before resource allocations :-). And in general if you allocate resources in most functions you're doing it wrong. Need global resource managers. Stack variables should only very rarely be resource owners.
RAII works just as well for heap allocated objects as it does for stack allocated ones.
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…
Is that a thing? No question that many concepts of OOP are in heavy need of reform, but I didn't know the basic idea of a struct was one of them.
I can sort of imagine this for quick-and-dirty things in untyped languages - but if you have types, passing dicts around everywhere seems like needlessly throwing away type safety - while it's also cumbersome to code and less efficient at runtime.
Earlier 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.
for a vi user, visually selecting a block to its matching end for cutting/pasting is the equivalent of coding photoshop
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.
In Ruby these are idiomatic enough to have a name and are built into the linter, so it'll yell at you if it sees that you're not using guard clauses. As a further refinement, I will often take tricky conditional logic and put them into a method that consists of nothing but guard clauses and a return true or false at the bottom of the method. In Ruby you can use ? and ! at the end of method names, so I'll give the met…
That's called a predicate and is used in Scheme as well.
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 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.