@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
Not white space. Parentheses. Redundant parentheses that the compiler doesn't need, because they match the default precedence rules, but which make the precedence explicit to the human reader.
I find on the contrary that parentheses would just be useless noise and thus make this harder to read. I know that *
has higher precedence than +
, and if I go into the trouble of actually parsing that line of code I can figure out what it does just fine. But if there's the appropriate visual grouping (i. e. adequately placed white space), I don't need to bother with checking the symbols, I can immediately identify the hierarchy of operations by just glancing at it, and that's helpful for quickly grasping the meaning of the code. On the other hand, if there's two additional sets of parentheses, I now have four additional symbols to identify to figure out what it does, and verify that the parentheses match up as I expect and not actually override the operator precedence.
And inb4 "but you can place the spaces wrong and thus obscure the meaning", this is exactly what the code auto-formatter does: It converts the code into featureless character soup with all (helpful or unhelpful) visual clues removed except for the bare, most basic syntax rules (which are almost never what I'm interested in when I'm reading code, the compiler can tell me perfectly well if the syntax is correct).
To me code auto-formatters seem to provide about as much value as those tools to auto-generate doc comments: their output is basically useless and only possibly better than the input if the original coder was absolutely careless; in all other cases the output is worse because it obscures the meaning of the code.