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.
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.
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.
> 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.
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.
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
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).
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.
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.
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.
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.
I wouldn't say, I hate tabs. But I strongly prefer not using tabs in source
code. Let me explain why. There are some languages and coding styles where it doesn't really matter. E.g. when you are always indenting by multiples of some indentation length. But there also languages and coding styles where you want to align stuff.
In the second two variant the indentation depends on the length of someFunctionName, so it is not necessarily a multiple of four or whatever your tab width is.
There are other similar situation when aligning in multiple columns, etc.
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.
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.
> 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.)
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.
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.