My tab is much wider than yours
“… your tab can go right up your …” And if we’re going to measure who’s got a wider one, let me point out that my space key is wider than your tab. Tab width is just one of many arbitrary things developers love to argue about, and no matter what you say, mine is always better than yours, even though there’s no true argument for either option.
Some colours are arbitrary - Mahana no Atua by Paul Gauguin Photo: Rawpixel
Don’t you just love it when you commit your code, make a pull request, and somebody rejects it because one line is 3 characters too wide and you need to fix it? Since that line of code is nested a few levels, and you have to follow a naming convention, you need to break a single simple operation into multiple lines. Whoever thought that’s more readable than a line with 3 extra characters?
Back in the days, standard punch cards had 80 columns, thus limiting line length to 80 characters. Early command-line systems kept that as the number of characters on screen, and even though files supported longer lines, it made sense to have your code fit on the screen without wrapping. Nowadays, however, you’ll find limits of 90, 120, 150 characters, or even some more random number. Who comes up with these numbers? Within your team it’s probably someone who only works on a 13’’ laptop and uses the terminal to write their code because they’re so hardcore.
Yeah, but …
I know what you’re thinking, you’re thinking about every single argument you’ve ever heard in favour of limiting the line length. Think again - are those arguments really about some specific line length, or are they actually about keeping each line of code readable and concise? Do these arguments apply to code, or are they really about something else, like Git commit messages where character limits encourage separating unrelated changes?
Tabs vs spaces
That’s another great debate; I’ve heard many arguments for one or another, perhaps the most convincing one being that everyone can adjust their tab size, so there’s no need to agree (and consequently argue) on how many characters to use per indentation level.
See where this is going? Someone preferring tab width of 2 characters will see their code neatly fit the 80 characters limit, while someone preferring tab width of 4 characters will potentially see some lines going over the limit. Linter, however, unless specifically set to use one of the two preferences for tab width, will happily count the tab as a single character.
So I was looking at your code
Back in my junior days, a higher dev (I thought about him as a senior, though looking back he was probably just a bit above me) came to me and said “So I was looking at your code, and it seems you’re using tabs. Could you please use spaces like the rest of us?” and then proceeded to show me my code in a terminal window with tabs spanning 8 characters.
As a fresh dev I just accepted that and proceeded to replace my tabs with spaces, and I’ve been using spaces ever since. A few years later in a situation like that, I’d probably keep fruitlessly arguing over which is better …
Sometimes arbitrary is fine
Despite everything I just wrote, as a project lead, I still enforce line length limits in my projects and push other devs to follow them. Granted it’d be better to limit how many variables, operations or function calls can there be in a single line before breaking it up, but implementing that takes work and I’m lazy, so [rolls dice, 6 times 20] 120 characters it is.