5 ms·

So much this. I had strong opinions on style until I found good autoformatters. Now I write horribly unformatted code and it comes out super clean and organized

So much this. I had strong opinions on style until I found good autoformatters. Now I write horribly unformatted code and it comes out super clean and organized as soon as I hit save. Now I don’t even really care what the standard is because it only affect reading code.

michaelmior 6y ago
I agree with sentiment but I don't think it's entirely true that it only affects reading code. When it comes to modifying existing code, I have to deal with whatever format the existing code was written in. For example, personally I hate working with code with tabs so I would find this frustrating. (As an aside, I'll admit this is really my problem and a rather silly one.) Of course one solution is to transform code on read to the current user's preferred format and then back to the canonical format on commit. Although this seems potentially error prone.
- ambicapter 6y ago
  > When it comes to modifying existing code You don't have to deal with anything as long as you're using the same formatter everyone else is using.
  - michaelmior 6y ago
    My point was that when writing new code, I can write it in whatever format I want knowing that it's going to be formatted the canonical way. But when modifying code, I have to work with code in one specific format that may not be my preferred format.
    - asutekku 6y ago
      Can’t you just set up a linter/formatter to your style, apply it to your style when editing and on save set it to the project style?
      - kevin_thibedeau 6y ago
        It fucks up the diffs in the codebase.
        michaelmior 6y ago
        How so? If the canonical format is applied every time you save, you'll always be doing a diff with files using the same format. Of course, it does mean the code in the diffs may not be in your preferred format.
        kevin_thibedeau 6y ago
        If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.
        michaelmior 6y ago
        If you're talking about moving from a codebase that did not use a consistent formatting style or a style that did not match the auto formatter configuration, sure. I was assuming a case where automatic formatting was done from the start.
        mcgoo 6y ago
        This is something that keeps coming back to me either as a feature or as a product of some kind - a tool that can stop this from getting in our way. The simplest and safest would be to apply the formatter to both the old and the new copy before diffing it. It ceases to be the actual difference at that point, but there are definitely two distinct use cases for diffs - one for humans to read and one for the machine to apply. The other case that would be amazing but even more of a stretch would be to rewrite the entire history. It seems like there is a spot for "different views of history" and you could do a no-difference merge to join the to histories as of now so that the actual history did not get lost. As I write this, it starts to sound like just a caching system for the idea above. This needs a highly reliable formatter of course... I have on occasion had code broken when formatting.
- libria 6y ago
  I feel like this is a team preference problem and not a formatter problem. The formatter will only do what you tell it, spaces or tabs. Looking at this another way, formatters are designed to "frustrate" devs into working only 1 way. If you think it's more helpful to have a codebase with mixed spaces/tabs with commits that express each developer's unique flair, then a formatter is not for your team.
  - VectorLock 6y ago
    Formatters are a way for one person who likes the formatters output to enforce their will on other who might not necessarily like that.
closed 6y ago
I would be a bit surprised if this is true, because it implies that when you're writing code that will be formatted you do not think of the reader's experience. This could be the case if you have extreme confidence in the formatter, but I have def seen some very funky black outputs. It seems like when writing people will likely do so with a model of how black will yield the final code in mind. (Eg "if I add more characters to this one line list statement, it will get exploded across 5 lines", and affect readability, etc..)
- pmiller2 6y ago
  Rather than “writing... with a model of how black will yield the final code in mind,” it’s more like “Oh, shit, Black made a real mess of this. Can I fix this without butchering the code?”
  - closed 6y ago
    Yeah--we're basically second-order black formatters now. Not writing code that looks nice, but writing code so a tool that writes code will make it look nice.
    - pmiller2 6y ago
      Not really. At least that wasn't my intention to say that. Most of the time, I find Black does a Good Enough Job(tm) that I don't care to mess with it.
- VectorLock 6y ago
  Formatters don't have the understanding like the developers do. Certain changes that might increase the understandability for a human might get obliterated if they don't conform to the rules of the autoformatter.

michaelmior 6y ago

I agree with sentiment but I don't think it's entirely true that it only affects reading code. When it comes to modifying existing code, I have to deal with whatever format the existing code was written in. For example, personally I hate working with code with tabs so I would find this frustrating. (As an aside, I'll admit this is really my problem and a rather silly one.) Of course one solution is to transform code on read to the current user's preferred format and then back to the canonical format on commit. Although this seems potentially error prone.

ambicapter 6y ago
> When it comes to modifying existing code You don't have to deal with anything as long as you're using the same formatter everyone else is using.
- michaelmior 6y ago
  My point was that when writing new code, I can write it in whatever format I want knowing that it's going to be formatted the canonical way. But when modifying code, I have to work with code in one specific format that may not be my preferred format.
  - asutekku 6y ago
    Can’t you just set up a linter/formatter to your style, apply it to your style when editing and on save set it to the project style?
    - kevin_thibedeau 6y ago
      It fucks up the diffs in the codebase.
      - michaelmior 6y ago
        How so? If the canonical format is applied every time you save, you'll always be doing a diff with files using the same format. Of course, it does mean the code in the diffs may not be in your preferred format.
        kevin_thibedeau 6y ago
        If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.
        michaelmior 6y ago
        If you're talking about moving from a codebase that did not use a consistent formatting style or a style that did not match the auto formatter configuration, sure. I was assuming a case where automatic formatting was done from the start.
        mcgoo 6y ago
        This is something that keeps coming back to me either as a feature or as a product of some kind - a tool that can stop this from getting in our way. The simplest and safest would be to apply the formatter to both the old and the new copy before diffing it. It ceases to be the actual difference at that point, but there are definitely two distinct use cases for diffs - one for humans to read and one for the machine to apply. The other case that would be amazing but even more of a stretch would be to rewrite the entire history. It seems like there is a spot for "different views of history" and you could do a no-difference merge to join the to histories as of now so that the actual history did not get lost. As I write this, it starts to sound like just a caching system for the idea above. This needs a highly reliable formatter of course... I have on occasion had code broken when formatting.
libria 6y ago
I feel like this is a team preference problem and not a formatter problem. The formatter will only do what you tell it, spaces or tabs. Looking at this another way, formatters are designed to "frustrate" devs into working only 1 way. If you think it's more helpful to have a codebase with mixed spaces/tabs with commits that express each developer's unique flair, then a formatter is not for your team.
- VectorLock 6y ago
  Formatters are a way for one person who likes the formatters output to enforce their will on other who might not necessarily like that.

closed 6y ago

I would be a bit surprised if this is true, because it implies that when you're writing code that will be formatted you do not think of the reader's experience. This could be the case if you have extreme confidence in the formatter, but I have def seen some very funky black outputs. It seems like when writing people will likely do so with a model of how black will yield the final code in mind. (Eg "if I add more characters to this one line list statement, it will get exploded across 5 lines", and affect readability, etc..)

pmiller2 6y ago
Rather than “writing... with a model of how black will yield the final code in mind,” it’s more like “Oh, shit, Black made a real mess of this. Can I fix this without butchering the code?”
- closed 6y ago
  Yeah--we're basically second-order black formatters now. Not writing code that looks nice, but writing code so a tool that writes code will make it look nice.
  - pmiller2 6y ago
    Not really. At least that wasn't my intention to say that. Most of the time, I find Black does a Good Enough Job(tm) that I don't care to mess with it.
VectorLock 6y ago
Formatters don't have the understanding like the developers do. Certain changes that might increase the understandability for a human might get obliterated if they don't conform to the rules of the autoformatter.