Normally I agree with treating code as a means to an end rather than an end to itself but I take a certain enjoyment in crafting in some way aesthetically pleasing code as well. I even find that if the code is "ugly" that there frequently might be a more eloquent and objectively better way of doing things. And a little time hand formatting I think is worth it if you're maximizing understandability and readability.

Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"

Consistent style is more important than each block of code being perfectly pretty. You can still argue aesthetics, but they need to be applied across the entire codebase. Never having to bother someone because their PR doesn't meet the formatting guidelines is well worth it.

> Consistent style is more important than each block of code being perfectly pretty

"Pretty", yes, but we're literally talking about using language to communicate. Consistency taken to extremes is harmful to communication.

I don't understand the worship that people have for consistency. STUPID inconsistencies are bad, yes, and yes, there are certainly arguments that about subjective matters that are a waste of time. But distilling everything down to the lowest common denominator of grunt-talking is very consistent and terrible communication. (Does that feel like a strawman? I'd love for it to be! Once people stop talking about consistency uber-alles we'll be discussing the things that I consider important.) Right now, the most common reaction is to dismiss any idea of communication through language as irrelevant, subjective, and a waste of time."

I’d agree that 100% consistency is harmful to communication, but the primary communication happening in programming is with a computer. Even when it comes to other developers looking at your code, their internal process is “let me simulate what the computer understands”.

Unless you are enforcing weird autoformat choices, everything should look pretty enough.

> the primary communication happening in programming is with a computer

Working in a team with 15 people on the same code base I disagree with this. Count the computer as one teammate

"Style" means things that the human sees. If it changes execution its not style any more. This is what tests are designed to enforce.

People at work nit: my code all the time. I just straight up ignore them. If they ask me why, I tell them to add an autoformat to our ci or shut the hell up.

Fwiw, i use an auto formatter but its got problems with certain rules so i switch them off.

The reason we dont have it turned on in ci is because these rules break code.

Yeah, auto formatter (or at least format validation) is a must.

There are two kind of painting. You can paint a wall/a building, or you can paint Mona Lisa.

This is the same for programming. Each dev have their own taste in term of code style and code formatting preferences. I was an early employee in a startup, and at some point I was able to tell who wrote a chunk of code just from the code style, it was fun :) but as company grown, and team got bigger, it got more "professional", now we have prettier which erases a big part of our code personality. If you believe like me that coders are artists you might find that a bit sad, but the truth is that most Enterprise software building is wall painting, and art doesn't have its place there. That doesn't prevent us from painting Mona Lisa at home though :)

I like the point in general, but I will say there are times when idiosyncratic formatting can really help understanding "this particular bit of code". Often it has to do with aligning values so that they are easier to read; if a code formatter was smart enough to at least understand the signal the programmer is sending, and maintain (or even improve!) that kind of formatter, it would be the best of all worlds.

One simple example is when you're parsing text and you have a long list of simple one-line if statements. I personally think it's wasteful and harder to read that block of code if you impose curly braces and new lines on that list of conditionals. This kind of formatting convention has been around for at least 40 years, and it makes the code more readable. I have yet to see an auto-formatter that doesn't turn that kind of code section into an unreadable mess.

Or key value lists where the keys have slightly different lengths.

It's possible to do both: https://designyoutrust.com/2019/03/in-berlin-there-was-a-gia...

There's also plenty of room for art in the choice of materials and colours as well as the shapes of buildings. Likewise, with code, if you limit yourself to only what one person can do, you'll end up with a very constrained view of what "art" means.

You will flip out when you discover “git blame” or, even better, GitLens on Visual Studio Code.

I find that if the auto formatter isn't dealing well with a section of code, it's usually an indication that the code architecture is off. Too clever, too verbose, too much nesting, trying too hard to make one-liners, etc.

There's a beauty that comes from simplicity, and code for matters, at least for me, are good of reminding me of that.

Not to mention it dirties up version control. It's a lot easier to tell which _significant_ things changed from the last commit when you're scanning a diff and no formatting changes are highlighted.

Ive seen heaps of autoformatters dirty up version control. Mostly when theyre fussing about new lines. I kind of wish autoformatters would just ignore new lines and focus on indentation alone. It would certainly cut down on the over zealous rules.

I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.

Wouldn't having the autoformatter run as a pre-commit hook alleviate this issue? (This is assuming you had already cleaned up all of the currently checked in code with said autoformatter)

Prettier specifically annoys me to no end with this problem.

If youre adding more attributes to a jsx component later and know it you might format to multiline early. It decides to undo your work and slow you down, because some arbitrary line length.

Similarly, if you go over that line length, on something you want single line for readability of structure, it just straight up does what it wants.

Im 100% on the auto format train but it has to go the gofmt route and only apply rules that are actually important and incredibly uncontroversial.

> It decides to undo your work

What you're missing here is that you're supposed to be using it all along, all the time. Format on save. Format on commit. Format on server pipelines. Format all the time. It can never 'undo' anything if it's what's providing the formatting in the first place.

Thats what im talking about. If you add text to a line, and it goes over a length, it will reformat a jsx element into about 5 lines instead of 1. Similarly, when you add more than it needs because you want consistency, or know youll add more, and the formatter runs, often it undoes your work.

Prettier lets you control object literal formatting by inserting/removing the newline after the opening brace, I'm not sure why they don't do that for JSX elements.

https://prettier.io/docs/en/rationale.html#multi-line-object...

If you really want 5 lines, add a dummy // in there and will be forced to use 5 instead of 1. Dirty hack, but it works.

That, or a prettier-ignore comment above the JSX tag. I find your solution more elegant, though.

My two cents: Write the comment's purpose inside it. "// Comment inserted to force prettier line break until more attributes are added"

Im talking about adding an attribute in the next 5 minutes, no, im not going to add a comment, or an ignore line while im editing a component. Those are really awful work arounds to a man made problem.

It's tunable. Pick a line length you all agree on and when it reformats after that, that's what you asked for.

If the rule never works for you, turn that one off.

If the rule is what you want 99% of the time but it made this one line look dumb, mark that one block #ignore and let the team decide in CR if that was the right call.

Most autoformatters are under active development, and updates to them often causes changes in their behaviour. So you have to have all devs agree on the precise version of the formatter used, and even then you still need to do regular commits that contain nothing but a run of the newest version of the formatter on the codebase, which sadly destroys long term git blame.

Chromium has a presubmit that enforces that code is autoformatted. However, it only enforces this for changed lines, and in practice, it works pretty well.

this is a solved problem, pin your packages.

But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.

I dont think people want to hear that there are still problems with autoformatting text.

Anyway, my point still stands, drop rules about line length and rules that care about inter line break positions and most of these problems go away.

Sure. Most large teams do this on a 6 month basis or when it is needed to implement something. Again, a solved problem.

This problem is caused by adding a formatter to your editor, instead of adding it to your project (or one of your contributors adding it to their editor). But if you adopt a formatter into the project, then this isn't a problem. Create one commit called "reformat all files", and then use `--ignore-rev` to never see it in your git log.

If your contributor is changing thousands of lines in a diff to fix a typo, ask them not to do that :)

My workaround is to run the formatted in the whole codebase as a separate PR, make the commit with a separate user that’s none of my colleagues (like “Prettier <[email protected]>”) and add that commit’s hash to a file in the repo. I then configure git to use that file for ignoring changes in git blame.

Now the code is formatted and additions won’t trigger reformatting the line or the file.

That doesn't necessarily mean that you need to check in auto-formatted changes. You can just autoformat the two revisions before feeding it to the diff program.

Of course, a lot of tooling simply isn't there for that, unfortunately, but that's what I see as the ideal solution.

We've found https://git-scm.com/docs/git-blame#Documentation/git-blame.t... very useful in these cases. When Prettier changes significantly, we run across the whole codebase & add the commit to an ignore file.

I agree with this wholeheartedly. Being introduced to gofmt a few years categorically eliminated a certain class of PR comments allowing PRs to be more focused on actual implications and logic.

Not to mention that if multiple people work on a codebase over time, if a very large project gets very old (like 20 years old), having consistent formatting goes a long way in allowing people to understand code that they may not have context for.

Agreed. I adopted the Wes Bos approach (drive Prettier from ESLint) and it's fantastic.

Any links? I only use it for react. I found eslint auto fix works well enough for node etc

I agree with you, but I’m not gonna lie: you had me worried with your first sentence. :)

I don’t know. I feel formatting choice can carry information and removing that information for conformity might be not worth it.

Huge plus!

Personally I vote to let people write code in the format they are most comfortable with and run the formatter as part of CI

Not sure I agree. Most coding is maintenance. Far better to adapt to whatever the coding style convention is.

I also believe that formatters should be "light-touch" and not have an opinion about every last thing. At that point I start thinking, "if you so smart, why don't you write the bloody code!"