3 ms·
For me, one of the prime drivers for how easy something is to grok, is how the formatting of the code lays out the logic within. He does a fair job with the la
by spacedcowboy 7y ago
For me, one of the prime drivers for how easy something is to grok, is how the formatting of the code lays out the logic within.
He does a fair job with the last incarnation, but I’d go further than that. As he says, compilers are smart enough to do variable storage optimisation these days, so break up that enormous Boolean into multiple bools (sameFirsName, sameLastName, sameDepartment, sameCompany) and then use the condition at the end (hasChanged) to be a simple combination of those other bools. It’s easy to lose a bracket and add it in somewhere wrong in a complicated expression. Simpler ones are easier to see and immediately understand without effort. When debugging, this is the coding-goal.
Now onto formatting. Do all the tests fit onto one line ? Fine, go ahead and do that, it’s an easy chunk to grok and the variable-names ought to read pretty much like English anyway. If they won’t fit onto one line, then for the love of all that’s holy, line up the conditions underneath each other, so it’s clear what logic is actually being expressed at a glance. This minimal effort contributes greatly to code clarity, IMHO.
You get simpler statements, and you get better formatting. For me, it’s an easy win. It’s not rocket science, it’s basically agreeing with his premises, but taking it a step or two further down the process.
- jdashg 7y agoWith our drive towards auto-formatting, we are losing degrees of expressivity of formatting. Bad code looks better, but good code can't look quite as clear as it used to.