5 ms·

> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no ap

> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team member who wasted all our time on that.

mattnewton 2y ago
I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
- zamadatix 2y ago
  This approach comes with the benefit of automatically fixing those who simply don't realize their editor's settings disagreed with/didn't pick up on the conventions the project follows.
- Wowfunhappy 2y ago
  > I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. ...it occurs to me, this feels like you're conforming to the tool instead of the other way around. Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?
  - nemomarx 2y ago
    I would think the issue is that if you format someone else's code, gitblame then sees you editing that code? Unless you can mark that commit as white space changes only somehow
    - senderista 2y ago
      You can tell `git blame` to ignore entire commits: https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2 https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
  - mattnewton 2y ago
    It’s more than white space, autoformatters can change a lot, notable will often change line numbers by introducing or removing breaks
- codetrotter 2y ago
  > an autoformatter with the config checked into git is a nice way around this. Yes. At my job we mainly use defaults of rustfmt in most repos. Some repos have rustfmt.toml in them. And the neat thing is that cargo picks up this automatically so there’s no per-repo config you have to do after cloning those repos in order to follow repo-specific formatting rules. In CI we have a step that runs cargo fmt --all --check And that exits with non-zero code if any formatting is different from what rustfmt wants it to be. Which in turn means that that pipeline stage gets marked as failed. In order then to get your changes merged, you have to follow the same formatting rules that are already in use. Which in turn is as simple as having cargo fmt --all run at some point before you commit. For example invoked by your editor, or from some kind of git hook or alias, or manually. It’s nice and easy to set up, and it means that every Rust source file within each individual repo follow the same formatting as the other Rust source files in that same repo. I don’t particularly care about what specific formatting rules each repo owner chose. (And the vast majority of our repos just use the defaults anyway.) All I care about when I’m working on code is that there is some kind of consistent formatting across the files in the project, and that formatting changes between commits from different people are kept to a minimum so that git log and git blame gives the info that you are interested in. So for me I am very happy that they do it this way at my job.
necovek 2y ago
Consistency makes it easier to compare apples to apples and oranges to oranges. Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file).
- jvanderbot 2y ago
  Well I just want to fix the bug or write the feature and move on, but some want other things from their code.
  - Tostino 2y ago
    That's the thing, without a standard formatter, a lot of IDEs use whatever their rules are. You can end up playing tennis because you just want to get that bug or feature done, you modify a couple lines of code in file X, Y, and Z, and now each of those files got reformatted by your IDE.
    - jvanderbot 2y ago
      Instead of agreeing apriori on a standard format for all files forever, it's better to disable formatting in your IDE (except auto-indent which should follow their format). That's what mine does anyway.
  - swatcoder 2y ago
    Yours is a good attitude in an org with thousands of engineers, where every change gets mediated through some process tool simply to avoid chaos. You'll be messing up the system if you step out of your lane, and you statistically don't even care about some particular project's health and future anyway. It's not a great one in smaller teams, which benefit from everybody quietly sweeping up whatever bit of the mess they run across. Not to say that justifies the petty and sometimes passive aggressive "tennis" that can happen in that world; that's just unprofessional ego-feeding behavior.
lijok 2y ago
Very few professionals do this. Most people writing code are not professionals.
lcnPylGDnU4H9OF 2y ago
Since we’re already on a Holy War About Arbitrary Things topic (and at the risk of igniting the whitespace wars anew), do you mind expanding on this? > I hate tabs This opinion seems common but I haven’t seen a practical argument against tabs among practical arguments (for an admittedly niche situation) in favor of tabs. This seems an appropriate place to ask about it.
- tehjoker 2y ago
  tabs are not great in Python because they can hide spaces, and that causes the code to break. in other code? i guess tabs are nicer because people can size them as they like on their devices.
  - beeflet 2y ago
    I use tabs in python and it works fine, I just enable "show whitespace" in my editor.
  - lcnPylGDnU4H9OF 2y ago
    > i guess tabs are nicer because people can size them as they like on their devices This is the only case that has me thinking that tabs are an actual solution to a relatively uncommon problem. I recall an anecdote about someone’s colleague whose eyesight was going bad, which required them to use a huge font size to the point that the width of the screen could fit just one or two words. Two spaces is less convenient than one tab when the text editor can be configured to render the tab as a one-character-width space. (That’s the “admittedly niche situation” I mentioned initially. I call it “niche” but I’d still hope most teams would be accommodating for such a situation.)
- PeterWhittaker 2y ago
  I simply find spaces easier to navigate. I don't always use vim-golf-winning movements, and when I am being lazy using hl or arrow keys, I expect to move a space at a time. Tabs violate that expectation. It's a visceral rather than a rational thing (which I suppose is implied by the word "hate" :->). I also have trailing spaces and all tabs highlighted for similar reasons.
johnisgood 2y ago
I follow the coding conventions used by the project, whether it is tabs, 4 spaces, or other preferences. For my personal projects, I use 2 spaces for indentation and maintain an 80-column width, as it fits nicely in my XTerm windows, making both code and Git commit titles and messages easy to read.
throwaway2037 2y ago
Your comment is a bit strong, but, in my experience, it is normal to have a couple of average and below devs who only ever comment about formatting in a code review.

mattnewton 2y ago

I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.

zamadatix 2y ago
This approach comes with the benefit of automatically fixing those who simply don't realize their editor's settings disagreed with/didn't pick up on the conventions the project follows.
Wowfunhappy 2y ago
> I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. ...it occurs to me, this feels like you're conforming to the tool instead of the other way around. Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?
- nemomarx 2y ago
  I would think the issue is that if you format someone else's code, gitblame then sees you editing that code? Unless you can mark that commit as white space changes only somehow
  - senderista 2y ago
    You can tell `git blame` to ignore entire commits: https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2 https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
- mattnewton 2y ago
  It’s more than white space, autoformatters can change a lot, notable will often change line numbers by introducing or removing breaks
codetrotter 2y ago
> an autoformatter with the config checked into git is a nice way around this. Yes. At my job we mainly use defaults of rustfmt in most repos. Some repos have rustfmt.toml in them. And the neat thing is that cargo picks up this automatically so there’s no per-repo config you have to do after cloning those repos in order to follow repo-specific formatting rules. In CI we have a step that runs cargo fmt --all --check And that exits with non-zero code if any formatting is different from what rustfmt wants it to be. Which in turn means that that pipeline stage gets marked as failed. In order then to get your changes merged, you have to follow the same formatting rules that are already in use. Which in turn is as simple as having cargo fmt --all run at some point before you commit. For example invoked by your editor, or from some kind of git hook or alias, or manually. It’s nice and easy to set up, and it means that every Rust source file within each individual repo follow the same formatting as the other Rust source files in that same repo. I don’t particularly care about what specific formatting rules each repo owner chose. (And the vast majority of our repos just use the defaults anyway.) All I care about when I’m working on code is that there is some kind of consistent formatting across the files in the project, and that formatting changes between commits from different people are kept to a minimum so that git log and git blame gives the info that you are interested in. So for me I am very happy that they do it this way at my job.

necovek 2y ago

Consistency makes it easier to compare apples to apples and oranges to oranges. Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file).

jvanderbot 2y ago
Well I just want to fix the bug or write the feature and move on, but some want other things from their code.
- Tostino 2y ago
  That's the thing, without a standard formatter, a lot of IDEs use whatever their rules are. You can end up playing tennis because you just want to get that bug or feature done, you modify a couple lines of code in file X, Y, and Z, and now each of those files got reformatted by your IDE.
  - jvanderbot 2y ago
    Instead of agreeing apriori on a standard format for all files forever, it's better to disable formatting in your IDE (except auto-indent which should follow their format). That's what mine does anyway.
- swatcoder 2y ago
  Yours is a good attitude in an org with thousands of engineers, where every change gets mediated through some process tool simply to avoid chaos. You'll be messing up the system if you step out of your lane, and you statistically don't even care about some particular project's health and future anyway. It's not a great one in smaller teams, which benefit from everybody quietly sweeping up whatever bit of the mess they run across. Not to say that justifies the petty and sometimes passive aggressive "tennis" that can happen in that world; that's just unprofessional ego-feeding behavior.

lijok 2y ago

Very few professionals do this. Most people writing code are not professionals.

lcnPylGDnU4H9OF 2y ago

Since we’re already on a Holy War About Arbitrary Things topic (and at the risk of igniting the whitespace wars anew), do you mind expanding on this? > I hate tabs This opinion seems common but I haven’t seen a practical argument against tabs among practical arguments (for an admittedly niche situation) in favor of tabs. This seems an appropriate place to ask about it.

tehjoker 2y ago
tabs are not great in Python because they can hide spaces, and that causes the code to break. in other code? i guess tabs are nicer because people can size them as they like on their devices.
- beeflet 2y ago
  I use tabs in python and it works fine, I just enable "show whitespace" in my editor.
- lcnPylGDnU4H9OF 2y ago
  > i guess tabs are nicer because people can size them as they like on their devices This is the only case that has me thinking that tabs are an actual solution to a relatively uncommon problem. I recall an anecdote about someone’s colleague whose eyesight was going bad, which required them to use a huge font size to the point that the width of the screen could fit just one or two words. Two spaces is less convenient than one tab when the text editor can be configured to render the tab as a one-character-width space. (That’s the “admittedly niche situation” I mentioned initially. I call it “niche” but I’d still hope most teams would be accommodating for such a situation.)
PeterWhittaker 2y ago
I simply find spaces easier to navigate. I don't always use vim-golf-winning movements, and when I am being lazy using hl or arrow keys, I expect to move a space at a time. Tabs violate that expectation. It's a visceral rather than a rational thing (which I suppose is implied by the word "hate" :->). I also have trailing spaces and all tabs highlighted for similar reasons.

johnisgood 2y ago

I follow the coding conventions used by the project, whether it is tabs, 4 spaces, or other preferences. For my personal projects, I use 2 spaces for indentation and maintain an 80-column width, as it fits nicely in my XTerm windows, making both code and Git commit titles and messages easy to read.

throwaway2037 2y ago

Your comment is a bit strong, but, in my experience, it is normal to have a couple of average and below devs who only ever comment about formatting in a code review.