Hacker News new | ask | show | jobs
by koito17 583 days ago
The penultimate paragraph of the article really shows its age.

  When there are unclear or conflicting rules ... [y]ou can end up with hilarious games like formatting tennis ...
Back then, formatters were rarely used, if at all. The major benefit of tools like gofmt, Prettier, etc. is that a major source of vacuous commits and code review has gone away.

In the case of Prettier, bikeshedding can still happen over the .prettierrc file, but it's not hard to make an argument for using the default configuration.

Formatters are something I miss whenever using languages without a widely-used formatting tool. For instance, in Common Lisp, code formatting is "whatever Emacs does when formatting the whole buffer". Depending on the exact package used (e.g. SLIME or SLY), the results of formatting the whole buffer may differ. Contrast this to languages like Go where there is one tool (gofmt) and it exposes no configuration, so there is no possibility of bikeshedding over code formatting.

3 comments

In new projects I usually add an empty .prettierrc file with a single comment:

  // Empty file. Use default Prettier settings. No rules here.
To make it clear for other people that it was not just a mistake that the formatter was missing its configuration or that no config file existed at all. Useful to deter from adding new rules because someone is capricious about their own preferences...
I like to put a haikus in spots like this:

    // Empty by choice
    // Use the Prettier defaults
    // No customized rules
Taking the time to write a specific one gives added weight to the decision to use the defaults as anyone adding a rule has to remove the haiku.
haiku: "empty by choice" is only 4 syllables
We probably need a CI job to count syllables.
Just add 'left' to the left.

"Left empty by choice" ...

aw, damn, the response I was looking for was "good bot"
Maybe even add a CI step that closes PRs if someone modifies formatter config files.
And fires them too, while we are at it!
I still play tennis with Black. But Black wins every time when I Ctrl+S. I still play tennis anyway because user-facing strings are " not '
Prettier docs recommend a line length of 80 characters because of a fundamental design flaw: Lines are greedy and cramming as much as possible into each line decreases readability as lines increase in size.
Yesterday I was running Prettier on an existing code base, and decided to go with 100. Even at 2-space indentation, 80 caused too many if-expressions to be split up. Google's JS styleguide also says 80. (I also have 450 character lines there, in a table of CSS classes for dark/light/selected/hover/disabled/focused modes. Leaving it long makes it much easier to confirm all modes set the right class.)

However, the benefit of automatic formatters is that if you really like 80 better, you can reformat before editing, and undo that before sharing your results.