Reconsider Prettier

PrettierConsideredHarmful.md

Prettier Considered Harmful

This is about the Prettier code formatting tool.

1. Prettier runs counter to the Agile Manifesto. Several key tenets of the agile manifesto are about empowering small teams to make decisions for themselves:

   • "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
   • "Continuous attention to technical excellence and good design enhances agility."
   • "The best architectures, requirements, and designs emerge from self-organizing teams."
   • "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

   Prettier removes this autonomy and prevents developers from being able to change or tune how they communicate with one another. Code is a form of communication, and code style is a tool that allows each developer to control how that communication is understood by others. Prettier removes that tool and replaces it with rigid adherence to a set of rules dictated by a team completely outside of the team who is using it.

   Said differently, imagine you were a painter trying to express a beautiful, flowing landscape using a palette of 128 or more different colors. Now, imagine that after your painting was complete, it was reduced to only 8 colors, but without any input from you. Prettier is that process for code.

   Without Prettier (16 million colors)	With Prettier (8 colors)
   Vibrant Beauty	Limited, Flat Range

   Photo by Tushar Rathour on Unsplash.

2. Prettier discourages developers from thinking about how to communicate more effectively. Related to point 1 above, code is read much more often than it is written, so we need team members who will think critically about how their code is structured and understood. Prettier discourages this kind of thinking by emphasizing that developers should focus more on coding and less on communicating. In the long term, this leads to code-like-hell projects with poor structure, low cohesion, and high amounts of coupling because it's removing the step in the process where developers look at what they have authored to see how it can be improved.

3. Prettier wastes the time it saves in arguments with the Prettier team. Prettier advertises itself as an "opinionated" tool to prevent bikeshedding so developers can focus on coding rather than arguing with other developers about formatting. But, several of the formatting conventions Prettier enforces are so poor that developers have wasted hundreds of hours arguing with the Prettier team about them in the issue queue. If the Prettier team is the steward of what is considered the new "standard formatting" for all coding languages, then it is not eliminating any arguments over code style -- it is merely moving the argument from being among teammates to being between a teammate and a member of the Prettier development team.

4. Developers who depend on Prettier limit themselves to only languages that Prettier supports. The Prettier team does not support all existing coding languages (e.g., C++) and their team cannot possibly keep up with every new programming language that emerges. But, related to points 1 and 2 above, developers become used to Prettier as a crutch to stop thinking about code formatting. This creates a dilemma -- what if a developer encounters a problem that is best suited for a language and toolchain that Prettier does not support?

   A developer in this situation is forced to make a choice among three options:

   1. The developer will have to start a team project using the new language and accept that code style will be sloppy.
   2. The developer will have to start a team project using the new language and enforce code style themselves by working with their team.
   3. The developer will stick only to using languages that Prettier supports because it's comfortable, even if those languages aren't the right tool for the job. This violates yet another tenet of the Agile Manifesto, "Working software is the primary measure of progress."

5. Prettier is a dependency with a shelf-life, like any other tool. As a logical extension of point 4 above, there is no guarantee that Prettier will always be maintained. Just like OpenSSL, there may be thousands of projects that depend on Prettier but it is likely developed by a much smaller team. That team could stop supporting Prettier -- especially if they no longer have the energy to keep arguing with developers about style, per point 3 above. If Prettier becomes unsupported, those thousands of projects will need to do one of the following:

   1. Find an alternative tool.
   2. Limit themselves to only the languages that Prettier supported when it became unmaintained.
   3. Return to the fundamentals of communication and self organization that they shortcut by blindly adopting Prettier in the first place.