How Tabs versus Spaces affects the display of code and the tool chain

I know, why don't I just reintroduce emacs versus vi, right? But bear with me, I'm going somewhere with this.

I'm getting to do another round of "generate a format to fit an existing code base". At least this time I'm not (entirely) responsible for starting the project without having this stuff in place: we recieved the starting code from upstream without auto-formatting support. Anyway, when I ran whatstyle over the existing code it told me we're using tabs. Which came as a total surpise to me. But the project is being built natively in Visual Studio and that thing seems to default to tabs. After cursing for a few minutes I calmed down enough to examine why I have a strong preference for spaces and decided that I didn't, in point of fact, have a reason. Just a habit. Which sent me off to the web to do some reading.

My reading showed me several things in a broad scope:

• Spaces are the dmoninate choice in most programming communities (even python which seems strange to me).
• Tab proponents are passionate.
• Lots of space people seem to be interested in giving the author control of the code presentation.
• Tab people seem to be interested in giving the viewer control, but there is also a streak of pedantic focus on meanig ("tabs are for indentation, spaces for alignment" is an idea I saw several places).

I also came across a really interesting argument: tabs are an accessibility issue. That is to say that folks with perceptual difference may be better served by controlling the representation. This might be people with sever focus issues wanting to increasing the visual indentation or a braile display using one explicit tab per indent to reduce wasted space. Not a point to be blithely ignored.¹

So lets assume, arguendo, that I am convinced. I going to start using tabs in all my new code bases. What does that mean?

Implications of using tabs

1. Line-length limits Many sets of coding guidelines include line length limits. These may be rigid, modestly flexible (you can overun by up to $N$ spaces to prevent other formatting ugliness), or purely advisory. In any case, they are suppose to provide a limit on how much horizontal space is needed to display the code in it's entirety. Only now different coders are starting different distances in on the same code. I don't see a simple solution to this issue that doesn't require going to the "third way" mentioned below, though I will conceded that it is less bad than the implications that follow.
2. Alignment of broken lines If you have line-length limits you may have to break long statements or expressions across more than one line. Typically the "extra" line(s) are displayed indented relative the initial line often taking their alignment from operators on the first line. If that alignment indentation is also achieved using tabs, then when viewer changes the tab-width they will mess up the aligned formatting. The fix for this is mentioned above: you use tabs at the start of the line to indicate indentation (and only indetatation) and then do alignment beyond the indentation with spaces.²
3. Avoid mixed cases at all costs With the exception of the post-indentation alighnment spacing mentioned above any mixed case is a nightmare in which almost no one sees anything reasonable. Automatic tooling should be provided to prevent either spaces at the start of a line or tabs after a space.³

A third way

Honestly, most of the problems identifed above are caused by mixing levels of control: the viewer is given control of the indentation but not of other aspects of the presentation. I'm not the first one to notice that, and not the first to suggest that the optimal solution is to give the viewer complete (or almost complete) control of the presentation. Editors should simply autoformat the incoming code to match the viewers preferences.

This isn't without it's own issues, of course:

1. Communicating about position in the code At least some of the time, coders discuss position in a file using line numbers, which will break if two programmers are looking at the code in different views. You can, of course, use references to named entities such as method definitions for many things, but that isn't always fine enough. Perhaps the tooling can provide a notion of addressible units (statements?) and the editor can display them in the view. Or you can display the "as stored" line number. But you need something.
2. Controlling churn on the repository You don't want formatting changes to generate activity in the repository, which means you can't let programmers check-in code formatted to their own preferences. You need to enforce a rigidly defined formatting for the purposes of storage.

Given the power of tools like clang-format, the stored-format/viewed-format part of the idea is entirely feasible, but I'm not aware of a tool that supports the addressibility requirement.

What will I do

I really think I need to talk to my team on this one, but we have tabs in the repository and a tool that can do something reasonable with them. We may be stuck with them.

---

¹ The accessibility argument is the viewer control argument, only with the weight of "we need to be fair to people having a hard time" behind it.

² And how does this interact with the accessibility argument?

³ Emacs provides something like this in Makefile mode

Bad webmonkey, no Mt. Dew!

Given the possibility that the title could be taken as a pejorative, I should get a few things out of the way:

• Web programming can be "real" programming. It is a cross-disciplinary task and there are so many subtleties and complexities that web programmers ought to be taken seriously.
• Web programmers don't have the luxury of having most of their mistakes take place off camera the way some of us do.
• In addition to the complexities of the programming environment they get to deal with UI (or UE, if you prefer) all the time. Poor things.

But ... those same bullet points explain why they get bagged on: their mistakes are highly visible, annoying, and they generally turn out to be something that some segment of the users consider to be "obvious". As in "How could anyone with half-a-brain not know that?!?" kind of obvious to some part of their audience. And they don't generally hear from the cohort who shares their ignorance.

The answer to that exasperated query is that it takes time, effort, and experience to become good at cross-disciplinary stuff. You need to know a few things in great depth, a larger number of things to moderate depth, and a little bit about a huge number of things. That takes time.

Now, twenty years ago web programming had a reputation for low barrier to entry. Is that still true? I don't hang around the right places to know what people say about it these days. But combining low barriers to entry with pretty high requirements for preparation is a recipe for disaster.

So, "What brought this on?" I hear you saying.

Well, not really because you're on the other side of the internet from me, I haven't hacked your microphone, and it's not clear that anyone actually reads this thing with any regularity. But I have a good imagination, so I hear you saying it anyway.

Setting my security questions and responses for a web site. Unfortunately,

• The street I lived on when I was ten years old had a two word name (not counting "Road": its name was a phrase), which the person who programmed the form apparently thinks is a thing that doesn't happen.
• I got my first job in a city in the US southwest named after a saint. In Spanish. So it, too, is two words. Again, the programmer apparently doesn't believe in such nonsense.

Now, young programmers in my end of the business are pointed at a few documents early on to give them a starting familiarity with some of the more trap-laden parts of our work. Things like What Every Programmer Should Know About Floating-Point Arithmetic and What Every Programmer Should Know About Memory (PDF link) . I would have thought that Falsehoods Programmers Believe About Names and Falsehoods Programmers Believe About Addresses would be reasonably obvious candidates for the same role among web programmers. In fact these kinds of document make up a little genre of their own, and it's one worth taking a little time to explore. I promise you'll find one or two that you're guilty of.

Rather than hurling imprecations at web programmers in general, or even at the miscreant in this particular episode I'll just ask anyone going into web programming to find some resources for how to think about these things. Please.

Human exception handlers

I've done a pretty good job of not contributing to StackExchange over the last few months, but I haven't been able to break myself of the habit of looking in. At first I could claim to be holding out hope that I would see something on meta.stackexchange that would let me change my mind, but at this point it's pretty clear that I just don't want to give it all up yet.

So I see things that, in the past, would have required me to do something and I have to sit on my hands instead. (Aside: they still haven't pulled my diamond. It's been more than three months!)

Today I see a situation that requires, in Jeff's words, exception handling: there is a user on a site who is posting dozens of pretty bad answers to old questions. By "pretty bad" I mean a range of things including "more wrong than right" through "pointless and not adding anything" to "possibly a useful insight but so badly phrased as to be more confusing than helpful". And they are putting up several of these an hour (I guess they have some time at home...). It's not being very productive on the rep front but in the past two days they've managed to net more than one hundred rep this way (averaging a bit over two points per post).

It's not something a ordinary user can do much about because any attempt to do so would be targeted voting or a sustained pattern of negative comments (which is to say "not nice"). It needs a moderator to step in a put the brakes on it. Stack Exchange moderators can use the contact users and suspension tools for on-going poor quality contributions, and this seems like a exemplar for the need.

A lot of things that call for moderator action are like this: a user exhibits a behavior that could normally be treated by other mechanisms with unusual intensity or in a manner to reduce the effectivness of the usual controls.