Looking back at it, just crazy how much effort and man-hours went to manually editing whitespace and arguing/nitpicking about it. This is something that should have been automated by the 90s.
Birth of Prettier
31–40 of 57 posts
Re: Birth of Prettier
#32Earlier quoted context omitted.
I'm not opposed to establishing a coding style and using a linter to enforce it. I'm opposed to doing that without getting buy in from the team. IMHO it's important to figure out whats important to the different developers on your team and finding a set of rules that works for them; as opposed to just adopting something that makes some people happy and tanks other people's productivity.
I agree that suddenly adding a formatter to existing code could be disruptive. But how does "buy in from the team" work over time? If you hire someone new and they don't like the format rules, do you stop using the formatter?
I think it depends on the situation. If it's just not their preference then there's probably no need for a change. However, if it's going to prevent the new person from doing their job then a change is probably justified.
Re: Birth of Prettier
#33Earlier 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…
Which tools are you using that allow custom linter rules? I'd like to try this on some of my repos
Re: Birth of Prettier
#34I strongly dislike and disagree with Prettier. From a practical standpoint, I disagree with the idea that coding style is just "bikeshedding". Coding style has a DRAMATIC impact on how readable code is and therefore how easy it is to understand. In my experience, fighting to keep code understandable is one of the most difficult and important parts of software engineering. In particular, by not allowing the user to ch…
> Just because something isn't important to you doesn't mean that it's not essential to someone else.
The problem with this as an argument is that its opposite is equally valid.
Team dynamics are definitionally not about the concerns of the individual. The team is not helped by one person's insistence on handcrafted whitespace.
Re: Birth of Prettier
#35Earlier quoted context omitted.
> I strongly dislike and disagree with Prettier. Have you ever worked in a large team where everybody has their own idea on how code should be formatted? If not, then I can understand your position. Do you get to review PRs where formatting changes make majority of the changes? Because some people don't use code formatters, others do but use different rules from each other. You may call this freedom, others may call…
I'm not opposed to establishing a coding style and using a linter to enforce it. I'm opposed to doing that without getting buy in from the team. IMHO it's important to figure out whats important to the different developers on your team and finding a set of rules that works for them; as opposed to just adopting something that makes some people happy and tanks other people's productivity.
> I'm not opposed to establishing a coding style and using a linter to enforce it.
Linters can enforce code formatting? Indentation and such.
> I'm opposed to doing that without getting buy in from the team.
That is generally a good principle for adopting any tool and not specific to Prettier or any other code formatter.
I have to admit I am somewhat confused about your objections to Prettier in particular.
Re: Birth of Prettier
#36I strongly dislike and disagree with Prettier. From a practical standpoint, I disagree with the idea that coding style is just "bikeshedding". Coding style has a DRAMATIC impact on how readable code is and therefore how easy it is to understand. In my experience, fighting to keep code understandable is one of the most difficult and important parts of software engineering. In particular, by not allowing the user to ch…
> In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read.
Prettier allows configuring the indentation style (tabs/spaces) and indentation size, see https://prettier.io/docs/configuration#editorconfig.
Re: Birth of Prettier
#37Prettier and other format-on-save tools remain a huge quality of life improvement. I also think it found success because the defaults and choices outlined in the article were very wisely chosen: very readable in almost every context. The right tradeoffs were made both in printing logic and psychology with options/rollout.
One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.
Re: Birth of Prettier
#38> One interesting side effect is that I changed the most number of lines of code company wide that year and got my name on the "blame" for most of the JavaScript files that existed at that time. So over the years I kept getting random people or scripts pinging me about code I had no idea about! Not sure who needs to hear this, but in case anyone runs into this problem, you can create a list of commit hashes that `git…
Wow! Definitely will use, when enforcing new eslint rules. Thanks for sharing this, i just love git :)
Re: Birth of Prettier
#39Earlier quoted context omitted.
+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…
Which tools are you using that allow custom linter rules? I'd like to try this on some of my repos
eslint and biome allow custom lint rules and it is not that hard to write new ones yourself.
Re: Birth of Prettier
#40Earlier quoted context omitted.
I agree that suddenly adding a formatter to existing code could be disruptive. But how does "buy in from the team" work over time? If you hire someone new and they don't like the format rules, do you stop using the formatter?
I think it depends on the situation. If it's just not their preference then there's probably no need for a change. However, if it's going to prevent the new person from doing their job then a change is probably justified.
People being prevented from doing their job because of code formatting? In my nearly 20 years of development, that statement was indeed true, but only before the age of formatters. Back then, endless hours were spent on recurring discussions and nitpicky stylistic reviews. The supposed gains were minimal, maybe saving a few seconds parsing a line faster. And if something is really hard to read, adding a prettier-ignore comment above the lines works wonders. The number of times I’ve actually needed it since? Just a handful.
Code style is a Pareto-optimal problem space: what one person finds readable may look like complete chaos to someone else. There’s no objective truth, and that’s why I believe that in a project involving multiple people, spending time on this is largely a waste of time.