Birth of Prettier
blog.vjeux.com
Birth of Prettier
1–10 of 57 posts
Re: Birth of Prettier
#2When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting.
I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on all of the files, setting up CI/CD rules to enforce it, and teaching everybody how to set up format-on-save in their editors. Some people whined about it ("I don't like the way it does curly braces! Waaah!") but I was persistent and unwavering.
All these years later, I'm elated that whenever I join a new company - engineering orgs almost always have all of this already set up, not just with JS/TS but almost every language out there. It makes getting up to speed on the actual content of the code so much faster.
If I join your engineering org and you aren't using enforced, automatic, opinionated formatting on every single line of code that gets written that's a huge smell.
Re: Birth of Prettier
#3When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting. I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on…
One of my main pet peeves of working with other developers is people breaking from conventions because "it is not good". Yes even if a convention is bad you should still follow it, unstandardized codebase is the main root of all evil in large codebases.
I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because they statically enforce code-style.
It has become standard feature in most languages stacks these days because of Prettier and gofmt.
Re: Birth of Prettier
#4What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom
Re: Birth of Prettier
#5When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting. I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on…
> format-on-save
A dystopian feature!
Re: Birth of Prettier
#6When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting. I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on…
One of my main pet peeves of working with other developers is people breaking from conventions because "it is not good". Yes even if a convention is bad you should still follow it, unstandardized codebase is the main root of all evil in large codebases. I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because…
+1.
I'm a huge fan of custom linter rules.
Instead of going through PRs and nit-picking stuff, I just create new custom linter rules that catch those team-specific or project-specific things.
This has the positive effect of making things way more welcoming for junior devs and newcomers. Nothing replaces getting the first PR with almost no PR comments thanks to a linter.
I hate that a lot of people read the assertion that "PR reviews are a form of creating an internal coding culture" and become human linters, only nit picking PRs for the power trip. This is not only annoying but also makes people ignore the more important parts of the review.
I even made it a rule in every team I managed: if something is bothering you constantly in PRs and it can be replaced by a custom linter rule, let it go and write a linter rule for that later. I only met two people in my career who opposed this, and that was 100% because it made their nit-picking redundant.
Re: Birth of Prettier
#7When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting. I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on…
> format-on-save A dystopian feature!
I'll do one better: In the recent teams I worked, we even had "organize imports on save".
Re: Birth of Prettier
#8What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom
Wouldn't that result in having to reorient yourself between the formatted/non-formatted files when comparing commits and messy code that is being worked on?
Mind, I do value auto-formatting but wonder about the navigational costs when used this way.
Re: Birth of Prettier
#9What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom
Wouldn't that result in having to reorient yourself between the formatted/non-formatted files when comparing commits and messy code that is being worked on? Mind, I do value auto-formatting but wonder about the navigational costs when used this way.
maybe code should be stored with no formatting, only the required whitespace, and the editors/viewers are responsible for applying formatting. Then formatting will never cause confusion in diffs.
Re: Birth of Prettier
#10Earlier quoted context omitted.
One of my main pet peeves of working with other developers is people breaking from conventions because "it is not good". Yes even if a convention is bad you should still follow it, unstandardized codebase is the main root of all evil in large codebases. I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because…
+1. I'm a huge fan of custom linter rules. Instead of going through PRs and nit-picking stuff, I just create new custom linter rules that catch those team-specific or project-specific things. This has the positive effect of making things way more welcoming for junior devs and newcomers. Nothing replaces getting the first PR with almost no PR comments thanks to a linter. I hate that a lot of people read the assertion…
I often say that “nit” comments on prs are bad. It’s either important enough to make a linter rule, or not important enough to mention.