Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Birth of Prettier

blog.vjeux.com

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Birth of Prettier

#21

Post by CodingJeebus »

harimau777 wrote: post #19

I 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…

The challenge is that it’s easy to find fundamental disagreements on a team on how a codebase should be styled, especially when the language itself doesn’t provide much guidance on styling convention. When that happens, it’s easy for a debate around styling to go on without ever finding consensus.

I’m way more open to adopting coding style that’s not my personal taste as long as it’s consistent and tools like prettier really help with that.

Re: Birth of Prettier

#22

Post by cheema33 »

harimau777 wrote: post #19

I 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…

> 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 it hell.

Re: Birth of Prettier

#24

Post by harimau777 »

whstl wrote: post #6
DanielHB wrote: post #3

Earlier 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…

The difficulty that I've run into is that one person's nit is another person's essential change. My experience has led me believe that there are several different ways that developers approach reading code; resulting in developers placing different value on different style rules.

For example, when I am skimming code I primarily look at the code's "shape" and "flow". Where is there iteration? What code blocks are mutually exclusive? How does the code bail if there's an error? Etc. Therefore, things like indentation style and function decomposition are important to me because I need to be able to quickly see the overall layout of the code.

As far as I can tell, other developers read code using more of a "depth first" style where the overall layout isn't as important. As a result, they tend not to care much about things like indentation style or decomposition.

Re: Birth of Prettier

#25

Post by harimau777 »

cheema33 wrote: post #22
harimau777 wrote: post #19

I 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…

> 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.

Re: Birth of Prettier

#26

Post by waisbrot »

fenomas wrote: post #17
schwartzworld wrote: post #10

Earlier quoted context omitted.

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.

I wouldn't go that far - to me what's important is that nits must be non-blocking. I.e. the author is free to ignore them if they disagree, and a PR review with only nit comments should be an approval. If those things are true, it's fine to have gray area between what's linted and what's mentioned in PR review.

+1

For example, "nit: maybe call the function updateCreditCard instead of updateCard"

If you disagree and think your function name is better (or that the two are equally bad), then I'm happy to go along with what you've got. But maybe you didn't think of this name or maybe I've convinced you. Either it's a quick fix (and no re-review needed) or you just dismiss my comment.

Re: Birth of Prettier

#27

Post by jjj123 »

normie3000 wrote: post #5
TranquilMarmot wrote: post #2

When 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 love format on save. I can type (or paste) ignoring whitespace, hit save, and everything pops right into place for me.

Also, stuff not auto formatting is usually immediate feedback that I didn’t match my parenthesis or have some other major syntax error.

Re: Birth of Prettier

#28

Post by harimau777 »

CodingJeebus wrote: post #21
harimau777 wrote: post #19

I 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…

The challenge is that it’s easy to find fundamental disagreements on a team on how a codebase should be styled, especially when the language itself doesn’t provide much guidance on styling convention. When that happens, it’s easy for a debate around styling to go on without ever finding consensus. I’m way more open to adopting coding style that’s not my personal taste as long as it’s consistent and tools like prettie…

I can see how that would be a challenge. I think the key may be to focus on identifying which things are just a given developer's preference and which are essential to their productivity. Like you said, I'm more than happy to adopt a style that isn't my personal taste. The problem comes when the style prevents me from doing my job.

Re: Birth of Prettier

#29

Post by waisbrot »

harimau777 wrote: post #25
cheema33 wrote: post #22

Earlier 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 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?

Re: Birth of Prettier

#30

Post by harimau777 »

fenomas wrote: post #17
schwartzworld wrote: post #10

Earlier quoted context omitted.

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.

I wouldn't go that far - to me what's important is that nits must be non-blocking. I.e. the author is free to ignore them if they disagree, and a PR review with only nit comments should be an approval. If those things are true, it's fine to have gray area between what's linted and what's mentioned in PR review.

100% agree! The pattern that I've found works well is:

Reviewing a PR with "Approval" status means that the comments are just suggestions.

Choosing "Comment" status means that the comments are optional but important enough that I want to make sure that you read them. If you come back and say "I read them but decided not to make any changes" then I'm happy to approve the PR.

Choosing "Request changes" means that the comments aren't just nits.

Post reply on HN