a companion discussion area for blog.codinghorror.com

Death to the Space Infidels!


#261

In all of this I have yet to see the main argument that caused me to abandon hard tabs in code nearly 20 years ago: documentation. Try taking a piece of code written using hard tabs and paste it into MS Word (where tabs stops are in inches or centimeters) or an e-mail or a web page. The results vary from marginally usable to unreadable.

I can’t image how horrible the code from an “elastic tabstop” editor would look when viewed in any other application. Once you start using something like that your code stops being a plain text file and becomes non-standard. Even though it is still a text file so it can be viewed in other applications you lose the intended formatting. It takes the problems with hard tabs and amplifies them.

Assuming that the code will only be viewed or edited in a particular program or group of programs is rather short sighted. You yourself may be in a situation where you have to view or edit a file in notepad or Word or an ancient version of vi. I know I have. Using all spaces may mean that you have to type and delete multiple spaces, but, the code will appear as intended in the word processor or old text editor and if you make changes you won’t have to go back later and fix the formatting.

I currently work as a contractor and follow whatever coding standards my client prescribes, but I feel fortunate that in the last 5 years I haven’t come across a single shop that used hard tabs.


#262

I think the third option – tabs for indentation, spaces for alignment – has an advantage when it comes to documentation. When coding on my widescreen, I prefer a large tab size for maximum legibility: four or eight columns per indentation level. However, that’s way too much for paper, so I use LaTeX’s listings package to set the tab size to two (\lstset{tabwidth=2}). The code will then display as if it was indented with two spaces per indentation level.

This way the original line numbers are retained as well, since I can just include the necessary lines from the source files themselves without reformatting it first.


#263

I think spacing/tabbing should be controlled by the IDE. I couldn’t live without the Correct Indentation function in Eclipse.

This way it doesn’t matter which how to format your code. Just make sure to hit Ctrl-I before checking in :slight_smile:


#264

@Anthony: Then I guess youíre out of luck, but thereís always the option of popping your code in an ìauto-indentî aware IDE or editor.

Some of us are just too attached to console editorsÖ


#265

If you have a standard formatting method for when code gets checked in, can’t you automagicaly transform from your preferred method to ‘team compliant’ and of course from team compliant to your preferred?

Don’t IDE’s do this for you already?


#266

Make sure everyone on the team has the same tab/space settings in the IDEs, otherwise version control and code reviews are full of nonsense changes.

Also makes it easy to change your mind later if you use a tool that can auto-format. Personally I don’t like auto-format but I have to admit it increases overall project readability and reduces changes in version control.


#267

Oh, and if your IDE’s whitespace (and other formatting) isn’t sophisticated enough to do what you need and share with team members…

…invest in a real IDE. Notepad is not a code editor. :slight_smile:


#268

Shneiderman found that when program statements were arranged in a
sensible order, experts were able to remember them better than
novices. When statements were shuffled, the experts’ superiority was
reduced. Shneiderman’s results have been confirmed in other studies.

I don’t feel like paying the $34 required to find out for sure, but it doesn’t sound like that study has anything to do with code formatting. It seems to be describing statement reordering. Or is the snippet misleading? Because if it’s about reordering lines of code it doesn’t support your thesis at all.


#269

If I try to analyse your post as a formal, logical argument
(http://en.wikipedia.org/wiki/Logical_argument), I get the following:

Premise 1: The tab character can be expanded differently in different editors.
Premise 2: Formatting code uniformly is very important for program comprehension.
Conclusion: You should not use tab.

Right? As quite common in logical arguments, there are some missing
premises. The conclusion is in no way valid without also including
the following:

Premise 3: Using tab will make the code display un-uniformly.

As you discuss in your post, indentation can be handled in three
different ways,

a) indentation is X spaces
b) tab is X spaces
c) indentation is tab (expanded to whatever number of spaces you prefer), alignment is space

where premise 3 is true for a) and b) but false for c). Since premise
3 is not always true, this means also that the above conclusion is not
always true.

Discussing premise 1 and 2 is almost like kicking in open doors;
there is no controversy with those. The controversy occurs when someone
decides we shall have such and such indentation behaviour and that
conflicts with the preferred display preference of some of the developers.
Specifying this as premises gives:

Premise 4: People have different preferences on what the optimal width of indentation is.
Premise 5: Reading code with a different indentation width than your preferred makes the code harder to read.

and the the complete argument then becomes

Premise 1: The tab character can be expanded differently in different editors.
Premise 2: Formatting code uniformly is very important for program comprehension.
Premise 4: People have different preferences on what the optimal width of indentation is.
Premise 5: Reading code with a different indentation width than your preferred makes the code harder to read.
Decision 1: Mr/Mrs/Miss/Group X decides that indentation is X spaces.
or Decision 2: Mr/Mrs/Miss/Group X decides that tab is X spaces.
Result: The code becomes uniformly formatted, but is harder to read than optimal for some of the developers.

I put argument in quotes and use result instead of conclusion since the
decisions are based on taste/personal opinion and this is not a proper
logical argument any longer.

In some cases this might be a fair enough strategy; it might be impossible to
make everyone happy. This consistent with what you write in your paragraph:

Choose tabs, choose spaces, choose whatever layout conventions make sense
to you and your team. It doesn’t actually matter which coding styles
you pick. What does matter is that you, and everyone else on your team,
sticks with those conventions and uses them consistently.

However, in some way this also signals screw those developers that have
a different indentation width preferences, and as the observant reader
have noticed there is a third possible decision which will make everyone
happy with regards to reading the code (although possibly not for writing
(but this is irrelevant)).

Consider the relation between reading and writing code. Code is written
in the range of 1-10 times by one person (including some editing and
possibly pair programming). It can however possibly be read by tens (or
hundreds/thousands) of other people, several (maybe hundreds of) times.
This gives that having code that is easy to read is several orders
of magnitude more important than code that is easy to write. I.e. how
simple or complex some issue is to write is is irrelevant if it increases
readability.

The overall goal of any formatting discussion is to increase readability.
In fact that is the only important factor, to let the code be readable.
As written in the preface to the first edition of SICP: Thus, programs
must be written for people to read, and only incidentally for machines
to execute…

The best result is therefore to write the code so that everyone can
use their own preferred indentation display width without forcing this
upon others.

Premise 1: The tab character can be expanded differently in different editors.
Premise 2: Formatting code uniformly is very important for program comprehension.
Premise 4: People have different preferences on what the optimal width of indentation is.
Premise 5: Reading code with a different indentation width than your preferred makes the code harder to read.
Decision 3: Mr/Mrs/Miss/Group X decides that indentation is tab, alignment is space.
Premise 6: Decision 3 makes the source code tab expansion width agnostic
and allow everyone to display the source code with their own preferred
indentation width.
Result: The code becomes uniformly formatted and optimal for everyone to read.

Side argument:

Premise 7: Easy to read is several orders of magnitude more important than easy to write.
Premise 8: Some people will feel that decision 3 makes the code difficult to write.
Conclusion: Premise 8 significantly less important than readability improvements and can be ignored.

Premises 1, 2, 4, 5, 6, 7 and 8 are always true. Always. Please verify,
try to think of some situation where it could be false (and should you
think you found one by all means let me know). Then verify my conclusions,
it could be that I have made some mistakes? However the only way I can
see that you should be able to reach some other conclusions is if I have
Ignored some premises. What should that be?


#270

Wow!

This is still an issue for lots of people. However, I gave up reading what everyone else said after the first 20 comments or so. Too much!

I am a team leader with a penchant for performing reformatting of non-compliant code. I only do this when I am trying to understand the code in question. We have a style guide which is ignored by one individual in particular. He doesn’t think its important since the computer doesn’t run source code, does it.

This used to bug the hell out of me a year ago but I have matured now.

These days, I no longer inspect his code more than others. I still do reformat checkins if I find non-compliant code when I am trying to understand something that needs changing.

I am 45. I believe that tabs are the right way but WTF do I really know. After all, I’ve only been doing this for 20 years. I stick to the org’s coding policy even if it is insane.

FWIW, my definition of insanity is:

  • only use spaces
  • 2 space indents
  • 8 space indents

I prefer 4 space indents have this is what we have at my current place of employment.

We also have a 2 blank lines between methods rule which helps separate things out a bit. We like it. Other orgs might not.

Now, if you really want to get me going we should have a chat about how equals signs in blocks of code handling alignment should be handled.

:slight_smile:


#271

Oops! Typo time.

What I meant to say was:

Now, if you really want to get me going we should have a chat about how equals signs in blocks of code handling assignment should be handled.

:slight_smile:


#272

@Nicolas: captcha should probably change once or twice… it seems the Chinese spammers have discovered the secret power of orange…


#273

Thanks for the great article. Your last sentence got our debate a good laugh! Well done, quite unpredictable. I’ve linked to it from my blog on the same topic where I cover how spaces are a better choice.

There are valid arguments on both sides of the spectrum, so it really boils down who make the call in your team.

But spaces are definitely for the more experienced developers. I wouldn’t go as far as saying tabbers are “morons”… but I will let you do it :smiley:


#274

Depends on how many editors you are using.

Generally, I’m pretty good about opening up my Python scripts (which is where this debate acutally matters , no?) in a single IDE; they’re one time only, generally.

But I’ve opened up a Python script in several different editors:

  • Geany
  • VIM
  • Emacs

It’s sad to say, but my favorite CLI editor, VIM seems to be causing all the trouble. Eventually, I’ll find the time to find out how big a VIM tab stop is and write a script to de-VIMify a script (or change VIM’s tab size).


#275

Add me to the moron list. I don’t think you can gloss over the semantic value of the tab that way. Using it over spaces is not a compression mechanism. A tab says to indent. Think of that as the storage MODEL. Now the VIEW can show the tab in whatever aesthetic manner the programmer is used to. Everybody can see the code the way they prefer without disturbing the underlying stored code.

It’s the 21st century now. If you insist on vi or emacs, take the 30 seconds it requires to set your tabstops and shiftwidth. (I guess you can tell which editor I started off with)

Just my two cents.


#276

How is there any arguement here? I hate it when I have to mess about with someone elses code trying to align everything with spaces. Just indent things properly with tabs.

Instead its like:

4 spaces used
5 spaces used
3 spaces used
4 spaces used.

Just press tab and you don’t have to worry about getting it slightly out of place. You press backspace and it takes away an indentation.

Don’t come crying to me when you have RSI spamming space and backspace thousands of times… :@


#277

But if an organization uses tabs, then everyone can have their own tab size (e.g. 2, 4, or 8, etc). There can be rules for indenting. For example, if using tabs, indent long lists of function arguments with only one tab:

functionCall(
	some_super_long_argument_to_this_function_needs_line_break,
	arg2_blah_blah_blah_blah_blah_blah_blah_blah_blah_blah,
	arg3_blah_blah_blah_blah_blah_blah_blah_blah_blah_blah_blah
);

#278

So much people actually share the same “sane” principles of how proper indentation should look like in the 21st century. But FIG somehow could still just force the world to adapt to the inferior space indentation. Sad story indeed.
Anyway, whoever wants to join in: Use PSR2R: https://github.com/php-fig-rectified/fig-rectified-standards
I wrote a sniffer for it: https://github.com/php-fig-rectified/psr2r-sniffer It is already way more powerful than any of those rulesets out there. Try it, help to improve it, spread the word!
Mark


#279

Ok, I love the idea of using tabs instead of spaces, is just natural for my mind… but how should tabs be used when the project has code guidelines about the length of a line of code? for example if the length of a line of code should not be more than 100 columns ( tabs can be diferent from one machine to other - this is what I like ), so at the end you are not sure what the length of a line of code for other programmer of the project. Is this an use case for spaces ?


#280

This is stupid, I use tabs since they actually do save space, operational costs, and provide better indentations than a space. If it’s stupid to format code, aka a document for human readability, with tabs, then it’s stupid to indent anything with tabs. Oh look at that, discourse uses tabs everywhere, better burn it all down. Tabs are easier both for humans, and machines, that’s just so stupid. Oh and also how is StackOverflow working out? Do we have enough ppl asking the same basic questions yet or have you solved that problem?