5 ms·

I don't understand why people have this fetich for automatic formatters. If you really want this, you should be using old style FORTRAN or something similar. Th

I don't understand why people have this fetich for automatic formatters. If you really want this, you should be using old style FORTRAN or something similar. The good thing about modern languages is that you don't depend on the location of code in the page for it to work. If you start worrying too much about exact formatting, you throw away this big advantage. I really prefer code in the location where I put it, not where are machine thinks it is best. And if you think that formatting is a problem to understand the code, let's get real: this is the smallest of the problems. There are tons of other things that make code complicated to read, like variable and function names, the particular style of your code, how you split it into classes and files, the algorithm you're using, and so many other, more important things. I can guarantee you that if a piece of code is well written, you can understand it independent of where you put braces or the number of spaces you're using.

derefr 5y ago
I take it that you don't work on a large corporate code-base / don't have to code-review other people's code? Auto-formatting (esp. when used as a pre-commit hook) means that changes people make to the style are ignored/reverted (and/or, that places where people introduce a different style in new code, are auto-formatted back into the existing style immediately, rather than that needing to be an additional commit later on.) Thus, no spurious diff lines from formatting. Thus, not having to wade through a bunch of "noise" diff-lines, to get to the "signal" of semantic changes at code-review time. Also, having auto-formatting on both your main branch + development branches, makes merge/rebase conflicts less likely to happen. (Which basically boils down to "fewer noise diff-lines" again.) In other words: auto-formatting makes code more machine-legible to syntax-blind parsers; which in turn allows tooling like diff(1) to be more helpful. (Yes, we could just have language-syntax-aware semantic-level diff/merge/etc. tools. Not sure why nobody ever made these. I bet this is one of those things where Lisp users have had it for ages but using their own parallel world of abstractions that doesn't exist in C/POSIX.)
- coliveira 5y ago
  This has nothing to do with formatting. When you create a change to a code base you should be submitting only the lines that are new/changed. If someone is submitting purely formatting changes, he/she's just wrong and you should reject that during review.
  - derefr 5y ago
    > If someone is submitting purely formatting changes, he/she's just wrong and you should reject that during review. If you add a line between two existing lines, and then insert after it a new blank line to serve as a sort of "paragraph marker", is that a "pure formatting" change? If you add a constant in a group of constants, whose name is longer than the existing ones, do you pad the spacing of the values of those constants so they line up with one-another? For that matter, if you fully-qualify a previously-unqualified and potentially-ambiguous identifier, is that a "pure formatting" change? Some auto-formatter tools do this, after all. These are things that people may or may not do in code-bases, that "fly under the radar" of even the most stringent of human code-reviewers, because they're so irrelevant to understanding the code. They're "fluff." But because of this, how people introduce that fluff is essentially random, and so the cause of a lot of diff noise. These are the things that auto-formatters can "lock down" to only happen a certain way. But I think you're missing the forest for the trees, as I mostly wasn't talking about pure formatting changes. What I'm talking about is more like: You add a formal parameter to a function. Before, the function's clause head was less than 80 characters. Now it's more than 80 characters. Do you break the formal parameter list onto the next line? If so, how far do you indent it? Do you split the formal-parameter list up so that each parameter is now on its own line? Etc. Done by humans with no strict standard, these sort of one-off judgements made arbitrarily will add up to "syntax rot" — not something you observe with your eyes, but a sort of "potential energy" of un-made formatting changes, that means that any given semantic change by a sufficiently-motivated human might become the impetus for a manual reformatting during that semantic change, such that that reformatting will happen at a random time, inflating a patch where affecting that additional code wasn't strictly necessary. (If you ask the programmer why they did it, they'll say they needed to "clean up the code they were working on" so that they could understand it well enough to apply the fix.) Which is horrible for both code review and merge predictability. On the other hand, an auto-formatting tool will apply that transformation exactly when it becomes necessary; and will pick some way of formatting the additional lines and stick to it. There's no "potential energy" there. At all times, the codebase is "at rest", with no chance of anyone introducing "arbitrary" (but actually left-over) formatting changes. Human formatting is like a sequence of DML statements in an RDBMS. Auto-formatting is like a sequence of operations against a CRDT. Given a bunch of changes run in a random order, the output of human formatters will be arbitrary, while the output of auto-formatting will be deterministic. Which is what you want, if you're doing complex things involving e.g. long-maintained stable branches for 1.x that cherry-pick changes from 2.x.
brtmr 5y ago
> The good thing about modern languages is that you don't depend on the location of code in the page for it to work. If you start worrying too much about exact formatting, you throw away this big advantage. Counterpoint: When using a formatter, I stop worrying about formatting. It's a job for a computer, done by a computer. Humans are bad at consistency and discipline, computers are great at it. I want to concentrate on the things that matter, and formatting isn't one of those. Especially in larger teams, consistent formatting is just nice. No conflicting styles in the same file, and more meaningful diffs.
- coliveira 5y ago
  If you really want to stop worrying about code formatting, just stop doing it. It is not really that important. I have never spent any time worrying about it, and I don't see why people would be upset about formatting. Moreover, using an automatic formatter will not fix it, because, guess what, there is no universal code formatter. All of them have different results and a long list of parameters. Determining the best way to use one will create more work for you as you manage your team, and will inevitably add a new step to your already complex building process. Just stop worrying and use that time in more productive ways.
  - RussianCow 5y ago
    > Determining the best way to use one will create more work for you as you manage your team, and will inevitably add a new step to your already complex building process. I don’t know. I write JavaScript at $DAY_JOB and setting up Prettier on our repos took all of ~30 minutes, with an additional ~15 to determine which options to use. (There aren’t many because Prettier is fairly opinionated.) I have seen far more time wasted quibbling about code styling in code reviews.
jan_Inkepa 5y ago
I've been thinking of working on an automatic formatter for one particular programming language in order to easily be able to guarantee consistency of the documentation examples for it. (I get occasion bug reports about stylistic inconsistency or inconsistent spacing in them every so often)
yashap 5y ago
Strongly disagree: - Not having to format my code manually at all, just letting the formatter do it for me, is a significant productivity win. I write code as fast as I can, with the minimum number of key strokes, in a way that would normally be super ugly, and it comes out the same. I have my editor setup to auto-format the current file on save, so it’s just type a bit of code with zero formatting, cmd+s, then it’s instantly perfectly formatted - For a codebase with 10s or 100s of devs working on it, uniform formatting does significantly help readability. Sure I can still read it if there’s dozens of different formatting styles going on, but I can read it faster if the formatting is always consistent - Re: the above, yes you can keep consistent formatting without a code formatter, with a style guide that everyone learns, and that you enforce in code reviews. But that’s a waste of time both for on-boarding new devs, and a basically neverending waste of time during code reviews. Also a waste of time writing and maintaining the style guide itself The first point helps me write faster, the second helps me read faster, and the third keeps code reviews and the like quicker. Code formatters are such a clear, easy win, especially with large teams, that it’s hard for me to understand why anyone would opt out of them. It’s not a MASSIVE win, but IMO it clearly makes for a more productive development environment, and they’re generally dead simple to setup.
- coliveira 5y ago
  I have worked on teams that do automatic formatting and others that didn't. I have never seen any advantage of automatic formatting. In my experience, people who like to complain about simple things like where to put braces or where to break a line will move the goal posts and start to complain about particular parameters of the formatter, or try to change the formatter to something "more powerful". People who don't care about location of braces will continue working without problems, and everything will be the same as before, just with the added complexity.
  - yashap 5y ago
    The point is not that any one code formatting style is best, the point is that consistency in formatting across a codebase helps you read code faster. Our eyes and brains are good at picking up patterns - consistent patterns lets our brains parse code faster than if every file is written in a different style. Furthermore, not worrying at all about indentation, spacing, brace placement, semicolons or not, etc. lets me write code faster, not just read it faster. Type it out with zero effort expended on formatting, save, editor auto-formats. It’s not that any of this saves crazy amounts of time, but it does make all of code writing, code reading and code reviews slightly faster. When it’s so easy to setup, why not do it? The only argument I can see against auto-formatters is that people like to put their own artistic touch on the code they write. I get that, but it wastes time, especially when everyone starts doing things in their own style. I’ve been working professionally as a dev for 9 years, also on teams that use auto-formatters, and teams that don’t. I think they’re a small but clear productivity booster. The only time I’d consider not using one is in languages where the formatter itself is super slow. But fast ones, where you can setup nearly instantaneous “format on save” (go fmt, prettier, etc.), no brainer.
dahart 5y ago
In addition to what @derefr said, in order to not want automatic formatting, first you have to get to the place where zero people in your team/company care about formatting & whitespace at all. Disagreements over whitespace consume people time, and those disagreements go away when automated formatting is used. This is the strongest reason in my experience to use automatic formatting: to eliminate time spent talking about formatting. Auto-formatting tools in editors exist, and they're very common, and they're not always configured properly, so people change formatting on accident. Sometimes formatting changes can cause code reviews to take more time than necessary. Having tabs in code can cause actual problems, for example, since tabs aren't the same size everywhere. This is not just a code understanding problem, and shouldn't be written off as trivial, IMO.
- deleted 5y ago
  [deleted]
School-Cotton 5y ago
I like automatic formatters (if they’re a deterministic function of AST to text) because I think of what I’m writing as a syntax tree, and the fact that it’s stored as text as a historical accident. I just want to write the tokens without ever thinking about where they go on the page, periodically save and let my formatter deal with it.
avl999 5y ago
Auto Format is not for the machine, it is for other humans who work with you.
paxys 5y ago
If you truly think that you have never worked on a codebase with a team size > 3.

derefr 5y ago

I take it that you don't work on a large corporate code-base / don't have to code-review other people's code? Auto-formatting (esp. when used as a pre-commit hook) means that changes people make to the style are ignored/reverted (and/or, that places where people introduce a different style in new code, are auto-formatted back into the existing style immediately, rather than that needing to be an additional commit later on.) Thus, no spurious diff lines from formatting. Thus, not having to wade through a bunch of "noise" diff-lines, to get to the "signal" of semantic changes at code-review time. Also, having auto-formatting on both your main branch + development branches, makes merge/rebase conflicts less likely to happen. (Which basically boils down to "fewer noise diff-lines" again.) In other words: auto-formatting makes code more machine-legible to syntax-blind parsers; which in turn allows tooling like diff(1) to be more helpful. (Yes, we could just have language-syntax-aware semantic-level diff/merge/etc. tools. Not sure why nobody ever made these. I bet this is one of those things where Lisp users have had it for ages but using their own parallel world of abstractions that doesn't exist in C/POSIX.)

coliveira 5y ago
This has nothing to do with formatting. When you create a change to a code base you should be submitting only the lines that are new/changed. If someone is submitting purely formatting changes, he/she's just wrong and you should reject that during review.
- derefr 5y ago
  > If someone is submitting purely formatting changes, he/she's just wrong and you should reject that during review. If you add a line between two existing lines, and then insert after it a new blank line to serve as a sort of "paragraph marker", is that a "pure formatting" change? If you add a constant in a group of constants, whose name is longer than the existing ones, do you pad the spacing of the values of those constants so they line up with one-another? For that matter, if you fully-qualify a previously-unqualified and potentially-ambiguous identifier, is that a "pure formatting" change? Some auto-formatter tools do this, after all. These are things that people may or may not do in code-bases, that "fly under the radar" of even the most stringent of human code-reviewers, because they're so irrelevant to understanding the code. They're "fluff." But because of this, how people introduce that fluff is essentially random, and so the cause of a lot of diff noise. These are the things that auto-formatters can "lock down" to only happen a certain way. But I think you're missing the forest for the trees, as I mostly wasn't talking about pure formatting changes. What I'm talking about is more like: You add a formal parameter to a function. Before, the function's clause head was less than 80 characters. Now it's more than 80 characters. Do you break the formal parameter list onto the next line? If so, how far do you indent it? Do you split the formal-parameter list up so that each parameter is now on its own line? Etc. Done by humans with no strict standard, these sort of one-off judgements made arbitrarily will add up to "syntax rot" — not something you observe with your eyes, but a sort of "potential energy" of un-made formatting changes, that means that any given semantic change by a sufficiently-motivated human might become the impetus for a manual reformatting during that semantic change, such that that reformatting will happen at a random time, inflating a patch where affecting that additional code wasn't strictly necessary. (If you ask the programmer why they did it, they'll say they needed to "clean up the code they were working on" so that they could understand it well enough to apply the fix.) Which is horrible for both code review and merge predictability. On the other hand, an auto-formatting tool will apply that transformation exactly when it becomes necessary; and will pick some way of formatting the additional lines and stick to it. There's no "potential energy" there. At all times, the codebase is "at rest", with no chance of anyone introducing "arbitrary" (but actually left-over) formatting changes. Human formatting is like a sequence of DML statements in an RDBMS. Auto-formatting is like a sequence of operations against a CRDT. Given a bunch of changes run in a random order, the output of human formatters will be arbitrary, while the output of auto-formatting will be deterministic. Which is what you want, if you're doing complex things involving e.g. long-maintained stable branches for 1.x that cherry-pick changes from 2.x.

brtmr 5y ago

> The good thing about modern languages is that you don't depend on the location of code in the page for it to work. If you start worrying too much about exact formatting, you throw away this big advantage. Counterpoint: When using a formatter, I stop worrying about formatting. It's a job for a computer, done by a computer. Humans are bad at consistency and discipline, computers are great at it. I want to concentrate on the things that matter, and formatting isn't one of those. Especially in larger teams, consistent formatting is just nice. No conflicting styles in the same file, and more meaningful diffs.

coliveira 5y ago
If you really want to stop worrying about code formatting, just stop doing it. It is not really that important. I have never spent any time worrying about it, and I don't see why people would be upset about formatting. Moreover, using an automatic formatter will not fix it, because, guess what, there is no universal code formatter. All of them have different results and a long list of parameters. Determining the best way to use one will create more work for you as you manage your team, and will inevitably add a new step to your already complex building process. Just stop worrying and use that time in more productive ways.
- RussianCow 5y ago
  > Determining the best way to use one will create more work for you as you manage your team, and will inevitably add a new step to your already complex building process. I don’t know. I write JavaScript at $DAY_JOB and setting up Prettier on our repos took all of ~30 minutes, with an additional ~15 to determine which options to use. (There aren’t many because Prettier is fairly opinionated.) I have seen far more time wasted quibbling about code styling in code reviews.

jan_Inkepa 5y ago

I've been thinking of working on an automatic formatter for one particular programming language in order to easily be able to guarantee consistency of the documentation examples for it. (I get occasion bug reports about stylistic inconsistency or inconsistent spacing in them every so often)

yashap 5y ago

Strongly disagree: - Not having to format my code manually at all, just letting the formatter do it for me, is a significant productivity win. I write code as fast as I can, with the minimum number of key strokes, in a way that would normally be super ugly, and it comes out the same. I have my editor setup to auto-format the current file on save, so it’s just type a bit of code with zero formatting, cmd+s, then it’s instantly perfectly formatted - For a codebase with 10s or 100s of devs working on it, uniform formatting does significantly help readability. Sure I can still read it if there’s dozens of different formatting styles going on, but I can read it faster if the formatting is always consistent - Re: the above, yes you can keep consistent formatting without a code formatter, with a style guide that everyone learns, and that you enforce in code reviews. But that’s a waste of time both for on-boarding new devs, and a basically neverending waste of time during code reviews. Also a waste of time writing and maintaining the style guide itself The first point helps me write faster, the second helps me read faster, and the third keeps code reviews and the like quicker. Code formatters are such a clear, easy win, especially with large teams, that it’s hard for me to understand why anyone would opt out of them. It’s not a MASSIVE win, but IMO it clearly makes for a more productive development environment, and they’re generally dead simple to setup.

coliveira 5y ago
I have worked on teams that do automatic formatting and others that didn't. I have never seen any advantage of automatic formatting. In my experience, people who like to complain about simple things like where to put braces or where to break a line will move the goal posts and start to complain about particular parameters of the formatter, or try to change the formatter to something "more powerful". People who don't care about location of braces will continue working without problems, and everything will be the same as before, just with the added complexity.
- yashap 5y ago
  The point is not that any one code formatting style is best, the point is that consistency in formatting across a codebase helps you read code faster. Our eyes and brains are good at picking up patterns - consistent patterns lets our brains parse code faster than if every file is written in a different style. Furthermore, not worrying at all about indentation, spacing, brace placement, semicolons or not, etc. lets me write code faster, not just read it faster. Type it out with zero effort expended on formatting, save, editor auto-formats. It’s not that any of this saves crazy amounts of time, but it does make all of code writing, code reading and code reviews slightly faster. When it’s so easy to setup, why not do it? The only argument I can see against auto-formatters is that people like to put their own artistic touch on the code they write. I get that, but it wastes time, especially when everyone starts doing things in their own style. I’ve been working professionally as a dev for 9 years, also on teams that use auto-formatters, and teams that don’t. I think they’re a small but clear productivity booster. The only time I’d consider not using one is in languages where the formatter itself is super slow. But fast ones, where you can setup nearly instantaneous “format on save” (go fmt, prettier, etc.), no brainer.

dahart 5y ago

In addition to what @derefr said, in order to not want automatic formatting, first you have to get to the place where zero people in your team/company care about formatting & whitespace at all. Disagreements over whitespace consume people time, and those disagreements go away when automated formatting is used. This is the strongest reason in my experience to use automatic formatting: to eliminate time spent talking about formatting. Auto-formatting tools in editors exist, and they're very common, and they're not always configured properly, so people change formatting on accident. Sometimes formatting changes can cause code reviews to take more time than necessary. Having tabs in code can cause actual problems, for example, since tabs aren't the same size everywhere. This is not just a code understanding problem, and shouldn't be written off as trivial, IMO.

deleted 5y ago
[deleted]

School-Cotton 5y ago

I like automatic formatters (if they’re a deterministic function of AST to text) because I think of what I’m writing as a syntax tree, and the fact that it’s stored as text as a historical accident. I just want to write the tokens without ever thinking about where they go on the page, periodically save and let my formatter deal with it.

avl999 5y ago

Auto Format is not for the machine, it is for other humans who work with you.

paxys 5y ago

If you truly think that you have never worked on a codebase with a team size > 3.