My biggest influence on coding style is working with other people's code. I know the temptation to write "clever" code and I've been (and probably still occasionally am) guilty of it myself, but it's not until you have to debug someones oneliner iterator which has !(i-j) as the stop condition that you start to appreciate dumb, boring, obvious code.

If having a series of if checks in a long list makes it readable, keep it that way. If it makes it more readable to rewrite it into a nested switchcase with a couple of ternary bits, go ahead. Just don't spend half a day wrapping it up into two layers of abstraction that will require an onboarding process for the rest of the team.

  • 4
    Simple code is good code (over-generalization, but you get the idea).

    Yesterday I was debugging some js I wrote a while ago and I couldn't figure out how the hell a few items were being added into an array on a map. Then I found this

    const map = {}

    const arr = (map[id] = array)

    This smartness cost a me a little bit of time, not a lot but it was still mildly annoying.
    I could've just done this:

    map[id] = []
    const arr = map [id]

    Much easier to read when skimming through the code. This code is not very bad, but it shows how trying to be just a little clever can drastically reduce readability.
  • 1
    Piles of if statements are never readable, they just take what should be multiple methods and cram them into one method. Similarly, switch statements are only reasable as pattern matching.

    Whenever I see those, I immediately refactor them into a map of predicate, function|expression, and an iteration method that applies them.
Add Comment