[Permagate]

> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends.

While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, rather than completely ignoring it (like code styles as you mentioned). He created Prettier, so I'm sure he knows the value of code styling.

[couchand]

Simply using the term "fluff" to describe the form of code shows a lack of respect that I find deeply troubling. Those that pay little attention to code style, form, names of things, etc. (including those who rely on the tooling to fix it for them) tend to miss other, arguably more critical, things. Sometimes, but not always, this happens because those errors are lost in a soup of poor formatting and copy-paste repetition.

[hinkley]

I had a coworker come to my desk one day, years ago. "Why did you add all that duplicated code to that file??" Huh? Oh, I didn't 'add' that duplication. I took two long files by two different authors, changed them to use the same white space, variable names, comment style and organization strategy. That's all I did. I didn't have the time at that moment to take the next step.

He came back four hours later and said that he couldn't stand it and he had refactored the code and fixed/written some tests.

Perfect. I learned long ago that there are ways you can start cleaning that will induce (some) others to participate.

He spent hours writing tests while I was working on an adjacent part of the code that had worse bugs in it. The work got done and a big piece of the code (this was a project I supported but didn't maintain) didn't, in the end, have my edit history all over it.

[collyw]

I see a lot of article that tell you how to improve code, and they often seem focused in the wrong area. Python's PEP for example, I see the value in it, but you can follow that to the letter and still have a badly designed application and confusing code.

[Chris2048]

Aren't style guides supposed to help write code that is more standard in style, and hence easier to read - because your brain will become accustomed to that style.

And PEPs cover many things.

[Vinnl]

But then again, actually writing a code formatter does show quite some respect ;)

[jredwards]

Other people's time is also valuable. Try not to write code that's impossible to read.

[cloverich]

I think pure style (e.g. that a linter would catch) and DRY could be treated separately. The former should always be followed. To the latter: I find weak or incorrect abstractions much harder to follow than repetitive code. And I find those much more commonly when implemented early rather than later.

There's definitely a balance, and if you know the type of problem you are solving ahead of time you can probably abstract early. But if you're just kind of feeling around in the dark, which seems to be relatively common in complex business applications (for instance), I much appreciate an implement-test-reflect-refator cycle.

[AstralStorm]

For actual redesign, you end up with a long true refactoring iteration when no new features can be added. There is no guarantee you will not repeat the same mistakes or make it worse.

It is a very tough sell to most customers.

The quick cycle does not scale with project size.