If you’re using tools that don’t handle tabs properly you should either use better tools, suck it up, or use spaces if you really need to (I will convert them to tabs on opening in my editor however). Github respects tab size preferences btw, but even if it didn’t, having Github display tabs with 8 characters isn’t a big deal, it’s not where you should be doing your work anyway (aside from casual browsing or the odd edit perhaps if you’re on the go). @heh already pointed out the rest of the flaws with your post
Modern tools still have their limits. Tried a trial version of Resharper on our code base at work, and after looking at our code base, it deleted itself from the hard drive after sending an email resulting in our company IP being banned from their web site.
On the other hand, I’m kind of worried that the next generation tool would have ordered a cruise missile strike on our source repository.
My text editor converts tabs to spaces as I tab.
To be fair, the real comedic paydirt of the final tab/space scene was the reference to the *nix text editor holy war.
Interesting. It does make a difference when you try to run python.The compiler fusses over the difference.
I’ll be honest. This is the reason I don’t tinker with python more.
A language where I have to futz with it more to compile or parse puts barriers between my thinking and making that thinking reality.
I missed where they controlled where the size of the team was regarded. Do larger organizations have spaces or tabs in their style guides? My experience was that one shop insisted upon tabs, the rest upon spaces in their style guide wikis.
Me, I prefer spaces for the simple reason that there will always be mixture, and zapping everything to spaces makes twiddling with indentation easier, like indenting a comment. But I normally just let IntellijIDEA or PHPStorm take care of the indentation for me.
alpine on a Mac, feeding all content it can’t handle to open, is a valid and modern way to handle email IMHO
Since I was a little developerling, I was always told to use spaces instead of tabs because tabs could be rendered in multiple ways and ruin your formatting. Of course, ever since I’ve been using modern IDEs I just have it render tabs as spaces so I don’t need to think about it.
Those are single-OS editors, aren’t they? If it can’t do at least three operating systems, again it is not really worth my time to develop expertise in it. If I need to code on a mac I’ll just use vi, because that is available on HP-UX, linux, Suns and various BSDs (and has an implementation in busybox so it’s by far the most likely editor on embedded systems). Learning how to do something in vi is at least five times (really, more like ten times) as effective a use of my time as learning to do something that will only work on a specific OS.
Basically learning editors is a low value activity compared to using them, but learning them makes using them more effective, so you have to find the sweet spot for your own trade… I do more systems integration programming than app programming, so single-OS editors are a bad investment for me. I’ve probably used 25 different editors professionally so far. Maybe more ¯_(ツ)_/¯ I no longer bother with debuggers or IDEs at all, I gave up on them decades ago because they just slow me down.
I agree with and endorse this!
My own snap hypothesis would be quite simply that, in this particular holy war, hard tabs lost. Not because they are inferior, in fact I think Go stands as an interesting outlier; they ship a canonical code formatter with the dev tools, and have apparently decided that hard tabs are better iff you can ensure that everyone uses them all of the time and I suspect they’re right. But it seems like in nearly every other language, to varying degrees, people have gotten tired of incessant formatting glitches and decided that whatever else you can say about them, at least soft tabs look the same for everyone.
Except, developers tend to be a picky and opinionated bunch. For my part I work for an employer in another country (and put up with all the paperwork that entails) just because I was adamant about the programming language I wanted to use. And take @caze who (with all due respect) likes his tabs hard, and if you disagree you can “suck it up” and use “better” tools, and if you come at him with some soft tabs he’s gonna fuck that shit up. I mean, I don’t want to infer anything about you personally, caze, I’m sure you don’t vent about this sort of thing at work the same way you do here. But then there’s people like a friend I have who is deep in the autism spectrum, an awesome programmer with his way of doing things and if you disagree then You Are Wrong. He literally spent years travelling the world to find anyone who would let him set up his stack just how he wanted it.
What I’m saying is, developers often have strong personal preferences, and we can be abrasive about it and even limit our employment opportunities over seemingly trivial details. There’s probably just as many such people in the soft tabs camp as the hard, and there’s maybe some of the wage difference that can be explained by soft-tabbers having more jobs to choose from. But also, I suspect the statistically significant difference might come from people like @orenwolf, who like hard tabs personally but in an interview or survey scenario they’re likely to respond “soft” as a way to signal that they are happy to go with the consensus to avoid friction. People like to hire people like that.
Will you convert them back when you’re done? Supposing it’s an open source project, say.
I think this is part of why the spaces camp makes more on average than the tabs camp, due to them being more in the group of “I’ll just do what the company style guide says”. I personally count myself in this group of prefer spaces but what the heck, mainly because I do have to deal with code that comes from different developers, and what I often see is spaces hidden in between tabs*. It just looks sloppy, but I won’t fight about it.
*Yes, I always look at invisible characters. Always.
You might want to check out “Tabs, spaces and your salary - how is it really?” which has a different and more insightful analysis of StackOverflow’s dataset.
I suppose I could set it up to convert the spaces to tabs on opening, work with the document, then convert them back to spaces when saving!
If I was involved in a project where the style guide says to uses spaces I suppose I’d have to work behind the scenes to foment rebellion, seize power and implement the correct way of doing things.
Thanks for the link, it’s a pretty good analysis. If I’m following correctly then it sounds like a soft tab preference correlates with experience using source control and contributing to open source, which are probably better salary predictors. I’d go a bit further and speculate that it might be experience collaborating in larger teams in general that’s having a causal effect on tab preference, since that’s the sort of environment where one will fast get tired of inconsistent whitespace. Experience with, or an aptitude for, collaborative work will surely also have a causal effect on salary.
The diplomatic approach, then.
I maded you this.
I laughed out loud at this!
Well, it was a quick chortle, so I think it counts.
The main reason why looking at the invisible characters counts? Paranoia of being the Mac guy amongst Windows users when I was starting out, and before Unicode finally won out. Lots of Office copy-pasting colleagues meant secret formatting characters were resulting in mysterious failures, and I was the one who was able to find them. It left me a wee bit paranoid.
This topic was automatically closed after 5 days. New replies are no longer allowed.