3 ms·

It depends. In fact the entire discussion is wrong, and neither rule has any real world value. People are all talking about the format of the code, while what

• KerrAvon 2y ago
  This is really the issue with the article -- it's the CS equivalent of pop-psych feel-good advice like "write a page every day and you'll have a novel before you know it." It doesn't solve your actual problems. It doesn't solve anyone's. You're not actually better off in the long run if every line in your source is a separate commit, unless you have the world's most basic program. This "it's more important to wrap your code at 80 columns than to understand how the cache hierarchy works" stuff is becoming worryingly endemic. Teamscale has built an entire business around fooling nontechnical managers into believing this shit is not only worthwhile, but should be enforced by tooling, and middle managers at FAANGs, who should know better, are starting to buy in.
  • stoperaticless 2y ago
    Whats wrong with tooling enforcing it? I mean, where you wrap is not important, and is best left to tooling (brain cycles and meeting time can be used for more important things)
  • thfuran 2y ago
    Cluttering up git line annotations and code reviews with people's dev envs fighting over where to wrap lines or whether there's a space after parens or whatever is a waste of everyone's time and an impediment to seeing the actual code changes. That's why tooling should enforce a format, not because there's particular importance to the exact enforced format.