3 ms·

My pet peeve: function getOddness4(n: number): if (n % 2 === 0): return "Even"; return "Odd"; While it is shorter, I prefer vastly pre

• CatAtHeart 2y ago
  I personally prefer the former as you can visually see the return one level of indentation below function name. It shows a guaranteed result barring no early-exits. Something about having the return embedded lower just seems off to me.
• cess11 2y ago
  I would add a blank line to push 'return "Odd";' from the if, and also add brackets around the if-body if the language allows. There are situations where I allow else, they tend to have side effects, but usually I refactor until I get rid of it because it'll come out clearer than it was. Commonly something rather convoluted turns into a sequence of guards where execution can bail ordered based on importance or execution cost. It isolates the actual function/method logic from the exit conditions.
• __oh_es 2y ago
  I feel guard clauses/early returns end up shifting developer focus on narrowing the function operation, and not an originally happy path with some after thought about other conditions it could handle. IME else’s also end up leading to further nesting and evaluating edge cases or variables beyond the immediate scope of happy path (carrying all that context!).
• brulard 2y ago
  Nice example of how subjective this is. I immediately thought the first one without "else" is clearly the winner. This is the problem with formatting rules. A codebase needs to have consistent style, even though that might mean nobody is fully happy with it. I for example can not stand semicolons in JavaScript. It is just a visual clutter that is completely redundant, and yet some people really want it there.
• bogomog 2y ago
  function getOddness(n: number): return (n % 2 === 0) ? "Even" : "Odd"; Lowest boilerplate makes it the most readable. If working in a language with the ternary operator it ought to be easily recognized!
  • culopatin 2y ago
    While this is simple and all, the English words if/else don’t require the reader to know the ?: convention. Depending on what background the reader may have, they could think of the set notation where it could mean “all the evens such that odd is true” which makes no sense. Its also very close to a key:value set notation. If/else leave no doubts for the majority of readers. It’s more inclusive if you will.
    • bogomog 2y ago
      That's why I gave the caveat that if using a language with the ternary operator, one should know that operator. Python tried using English words for a ternary, but I think that's awkward from a readability perspective. A limited set of symbolic syntax improves readability over using words in my opinion, there's less text to scan.
    • erikerikson 2y ago
      Learning the basic operators of the language seems like table stakes. Choosing one of world's spoken languages over others seems to be the opposite of inclusive.
  • ajuc 2y ago
    I love code golf as much as anyone, not sure it's worth it on such small methods tho. Any of the propositions would be fine. Anyway: def oddness(n): return ["Even", "Odd"][n % 2] BTW this trick with replacing if-then-else with a lookup is sometimes very useful. Especially if there's many ifs.
    • pasc1878 2y ago
      Or your write in APL
• zoogeny 2y ago
  90% of the time I prefer the first. I am allergic to indentation and I hate anything remotely like: function foo(a) { if (a) { return doThing() } else { return Error(); } } I like all of my assertion and predicate guards nicely at the top of a function: function foo(a) { if (!a) { return Error() } return doThing() } And for that reason, I would probably go for getOddness4 even though I see your point.
  • stared 2y ago
    In case of handling exceptions (and similar stuff), I also prefer avoiding unnecessary nesting. For two (or more) equally valid, I prefer keeping same nesting.
• makeitdouble 2y ago
  If it's this short, the ternary operator would be the absolute best option IMHO. If any of the clauses are much longer, the first option reads a lot better if it can be a guard cause that returns very quick. If neither options are short I'd argue they should be pushed away into scoped and named blocks (e.g. a function) and we're back to either a ternary operation or a guard like clause.
• BlackFly 2y ago
  The asymmetry is apparent if the code gets refactored to continuation/callback style or mutation of a more complex data structure, the first method will fall through and execute the second instruction set. Return is a special operator in this sense in that it breaks control flow and the ordinary control flow of the first method is not capturing the exhaustiveness of the two cases. In idiomatic rust, return isn't used except for exceptional cases that break the control flow of the method and the second example is more commonly seen without return statements at all. Idiomatic python also typically early exits in the beginning with a return on invalid parameters or state with a tail position return being the usual actual return value. Because of these conventional practices, breaking the exhaustive if-else control structure makes the indented return appear exceptional (like an invalidity). If you follow these conventions than naturally the return statement begins to appear redundant except in the break-control-flow cases and the choice of the rust convention begins to make sense: in all languages return is a statement equivalent to break.