Tabs vs Spaces

[enk]

If someone using an 8-character stop has to deal with lines longer than 80 characters, then too bad; he can just set it to 4-character stops, and you're almost no worse off than if you had used spaces in the first place. (In fact, if this person is editing the code, he'd probably need to change settings anyway if you used spaces, lest he start inserting 8 of them where there should only be 4.) At least with tabs you've given him a choice of (1) not worrying about the 80-col limit, (2) saying that his preference for 8-space tabs overrides his preferences for 80-col limits and leaving the settings the same, and (3) saying his preference for 80-col limits overrides his preferences for 8-space tabs and changing to shorter tabs.

There's something wrong in there, but I can't really put my finger on it.

Maybe I want my code to look good for my sake, not theirs..?

[Amnesiasoft]

But mebe I's completely misunnerstannin this de-bate.

Yes, yes you are. Programming is usually done in a monospace font, which means spaces work just fine for alignment. And many people have different opinions on how far code should be indented in (some say 8 (I believe Linus falls in this category), some 4, some 3, and even some insane people think tabs should be 2 spaces). You use tabs for indentation so people can have lines of code indented however far in they want. And sending a person code in PDF format would just be silly. Not only do PDFs suck (if you think they don't, that's a debate for another thread), you don't get the code to look the way you like it (not just limited to indentation, but coloring also), it's not in a form that's directly useable for you, meaning you have to go to even more work to copy and paste it. Not that it's difficult to do, but it's annoying and unnecessary.

[Anpheus]

Really, I can't imagine coding in a non-monospace font unless it supported TeX like expressions. If you're going to make it look less like code and more like 'real math,' make it actually have mathematical expressions and operators.

[TomBot]

Really, I can't imagine coding in a non-monospace font unless it supported TeX like expressions. If you're going to make it look less like code and more like 'real math,' make it actually have mathematical expressions and operators.

A language that could interpret TeX-like expressions would be a blight upon humanity. Before you know it, we would have single letter or Greek variable names, or variables that differ only in their case, font, or whether they're bold or italic or blackboard bold or have an arrow over them. We'd have implicit summation, matrix elements accessed by using the lower-case version of the matrix with subscripts, made up operators, and different operators overloaded to do the same thing by different authors. Every line of code would need half a page of comments to explain what's going on. Mathy code would be worse even than Perl.

[davean]

Really, I can't imagine coding in a non-monospace font unless it supported TeX like expressions. If you're going to make it look less like code and more like 'real math,' make it actually have mathematical expressions and operators.

A language that could interpret TeX-like expressions would be a blight upon humanity. Before you know it, we would have single letter or Greek variable names, or variables that differ only in their case, font, or whether they're bold or italic or blackboard bold or have an arrow over them. We'd have implicit summation, matrix elements accessed by using the lower-case version of the matrix with subscripts, made up operators, and different operators overloaded to do the same thing by different authors. Every line of code would need half a page of comments to explain what's going on. Mathy code would be worse even than Perl.

You mean APL?

[EvanED]

I've always wished that program editors would support formatting commands in comments. You could include graphics in comments (or, even better, embedded objects a-la OLE), text formatting, hyperlinks to other points of code, etc.

If you did it right, it could just be an HTML-ish syntax in the comments, and if you opened it in another text editor, you'd just see "// <img src="linked-list-pic.jpg" />" instead of an image.

[!xobile]

I've always wished that program editors would support formatting commands in comments. You could include graphics in comments (or, even better, embedded objects a-la OLE), text formatting, hyperlinks to other points of code, etc.

If you did it right, it could just be an HTML-ish syntax in the comments, and if you opened it in another text editor, you'd just see "// <img src="linked-list-pic.jpg" />" instead of an image.

No, comments are not meant to have images and links, thats what documentation is for.

[crazyjimbo]

I've always wished that program editors would support formatting commands in comments. You could include graphics in comments (or, even better, embedded objects a-la OLE), text formatting, hyperlinks to other points of code, etc.

If you did it right, it could just be an HTML-ish syntax in the comments, and if you opened it in another text editor, you'd just see "// <img src="linked-list-pic.jpg" />" instead of an image.

Find your favourite open sourced editor and go for it. If it's useful it'll catch on.

No, comments are not meant to have images and links, thats what documentation is for.

Surely comments that ARE documentation are the best form of comments. Having the documentation right on hand when coding is very useful. So long as they don't get in the way of course, and this is difficult line to tread. But that line already exists anyway.

[EvanED]

No, comments are not meant to have images and links, thats what documentation is for.

Personally, I disagree, and think that the idea of external documentation that says what the code is doing is a silly idea that I wash was outdated.

External documents are good for architectural descriptions and high level views of what's going on, giving an idea of where to look for a specific function, etc., and if your API is meant for "external" use. (In other words, someone is going to use it as a library; this could be someone else on your project.)

But if your documentation says "this is how this part is implemented", it should be colocated with "this part". It's more likely to stay up to date as "this part" changes and it's more convenient for use.

I assume you put all your explanatory comments in external documentation, because after all, the source file is meant to have source in it?

Find your favourite open sourced editor and go for it. If it's useful it'll catch on.

Except I don't like coding in any open source editor. As I've said in a few threads, I like IDEs. And for C++, which is the language I use most of the time, Visual Studio is far enough ahead of the open source IDEs that this feature wouldn't change the balance.

I also don't have time, and a few other projects I'd do first.

[Anpheus]

A language that could interpret TeX-like expressions would be a blight upon humanity. Before you know it, we would have single letter or Greek variable names, or variables that differ only in their case, font, or whether they're bold or italic or blackboard bold or have an arrow over them. We'd have implicit summation, matrix elements accessed by using the lower-case version of the matrix with subscripts, made up operators, and different operators overloaded to do the same thing by different authors. Every line of code would need half a page of comments to explain what's going on. Mathy code would be worse even than Perl.

I think comparing anything to Perl is an insult. That said, you should seriously look into alternatives that are TeX-like but Not TeX. Fortress is one of three programming languages being drafted as a replacement for Fortran to be used on massive multi-processor machines. It has a number of innovative and powerful language features such as an entirely ASCII-based input with rendered unicode or TeX style output. The result is that the language when rendered looks good, can be edited with notepad or any other text editor still, and doesn't confuse users with by using full unicode which, as you are well aware, shares symbols at dozens of codepoints. Particularly notorious is that most Unicode fonts use the same grapheme for the latin letter 'a' as every other page, be it Cyrillic or otherwise. I understand that would be confusing, so do they, so please don't make assumptions.

TeX-like != TeX. Programming in TeX would be a nightmare, imagine one symbol being two different variables, the only difference between the two being the kerning? Even then, I can't imagine it being more of a symbolic nightmare than Perl; in a proper IDE that would distinguish between the two symbols and allow you to customize, visually, what the symbol looks like so that you could distinguish them.

[TomBot]

I guess what I'm saying is that I'm leery of allowing code to be formatted as beautifully as math in textbooks, because I fear it will encourage people to write code as though they're writing equations, and this goes against good coding practices. I'm not intending to disparage the syntax TeX uses to encode this formatting.

The thing I find most annoying about physics, and many of the more abstract areas of computer science (my field), is that particularly single letter variable names are a huge impediment to understanding. There will be a paragraph explaining, in the most economical way possible, what the names of the variables mean, and then a nicely formatted equation, and then they will continue to use the letters in the text. To understand any of the equations, you have to store the meanings of the variables in your short term memory and substitute them into the equation to form a sentence you can internalize.

Another example of a formatted language is Mathematica. You can make arbitrarily beautiful expressions, which at some level is just a string of text interpreted by the kernel. And partially because of that, and partially because it's mathematicians that use it, you end up with lots of single-letter variable names, which as you can see, I view as the original sin.

As for comments - I think the most important thing, but most often ignored, is to have a paragraph or so in a header file saying what the class is intended to be used for. It needs to be in the header file, because it it's external, than people won't be able to find it and people won't keep it updated. Descriptions of the functions are less important and can stand to be much shorter than some people make them. There are already lots of standards that let you just put HTML or other markup in comments, and have a program compile these into shiny HTML documentation. I guess that's a reasonable idea.

[Anpheus]

On the other hand, in a proper language like say, Mathematica or any other, the variables can be substituted at will, so any representation works. You could just as easily call a function using another variable name in Mathematica and get a function in terms of the new variable. If I do f[x_]:=-16x^2, and then do f[TimeSpentFalling] I get -16TimeSpentFalling^2.

I think the single letter variables isn't as much a problem as long as you choose those aptly, and particularly in math and physics, it's not going to be a problem. The problem is when you try to use single-letter variables outside math or physics, where there is no established and community-wide interpretation. If I type phi in Mathematica, there is an implied meaning there (I forget, however, if Mathematica defines it as a constant though.) If I use theta, it's implied I'm talking about angles, stuff like that.

I think it's no worse than operator overloading in C++, and while that can be done horribly poorly, is it so bad that the language would be better without the feature? I don't think so. You can write terrible code in any language.

[zenten]

I guess what I'm saying is that I'm leery of allowing code to be formatted as beautifully as math in textbooks, because I fear it will encourage people to write code as though they're writing equations, and this goes against good coding practices. I'm not intending to disparage the syntax TeX uses to encode this formatting.

The thing I find most annoying about physics, and many of the more abstract areas of computer science (my field), is that particularly single letter variable names are a huge impediment to understanding. There will be a paragraph explaining, in the most economical way possible, what the names of the variables mean, and then a nicely formatted equation, and then they will continue to use the letters in the text. To understand any of the equations, you have to store the meanings of the variables in your short term memory and substitute them into the equation to form a sentence you can internalize.

Another example of a formatted language is Mathematica. You can make arbitrarily beautiful expressions, which at some level is just a string of text interpreted by the kernel. And partially because of that, and partially because it's mathematicians that use it, you end up with lots of single-letter variable names, which as you can see, I view as the original sin.

As for comments - I think the most important thing, but most often ignored, is to have a paragraph or so in a header file saying what the class is intended to be used for. It needs to be in the header file, because it it's external, than people won't be able to find it and people won't keep it updated. Descriptions of the functions are less important and can stand to be much shorter than some people make them. There are already lots of standards that let you just put HTML or other markup in comments, and have a program compile these into shiny HTML documentation. I guess that's a reasonable idea.

You're ok with using single letters for throwaway counters and whatnot though, right?

[TomBot]

You're ok with using single letters for throwaway counters and whatnot though, right?

In very limited circumstances. Particularly if the variable isn't even being used. That is, I'd allow:

Code: Select all

for(int i = 0; i < 10; ++i)
    cout << "foo" << endl;


However, in cases where you're indexing an array, I'd prefer a more useful name. For example:

Code: Select all

Person people[num_people];
for(int person = 0; person < num_people; ++person)
    cout << people[person] << endl;


Some people would use "n" instead of "person", but I would want to stay away from that.

I'm also OK with "x" and "y", if you're actually talking about x and y coordinates. "i", "j", and "k", however, are unforgivable. Also, if the loops are nested so you have to keep track of multiple index variables, they should have good names.

If you're just storing the result of a calculation, or an intermediate calculation, or the input to a calculation, you should use a good name. Don't do this:

Code: Select all

float compute_kinetic_energy(float m, float v)
{
    return .5 * m * pow(v, 2);
}


I know enough physics to guess that m and v are mass and velocity, but I shouldn't assume the reader does. This goes doubly if there isn't even a convention, and you're just abbreviating things for the heck of it.

[EvanED]

You're ok with using single letters for throwaway counters and whatnot though, right?

In very limited circumstances. Particularly if the variable isn't even being used. That is, I'd allow:

Code: Select all

for(int i = 0; i < 10; ++i)
    cout << "foo" << endl;


However, in cases where you're indexing an array, I'd prefer a more useful name. For example:

Code: Select all

Person people[num_people];
for(int person = 0; person < num_people; ++person)
    cout << people[person] << endl;


I think you're being too restrictive. For that loop, I would actually rather see a shorter name, maybe p. But i is such a idiomatic loop variable that it would be fine too IMO.

Now, if your loop body is longer than a couple lines, or if you are nesting loops, then I revert back to "I want a descriptive name."

(Though this too would break down in special circumstances. For instance, say you were doing some generic matrix operation or something; then i and j would be fine. The only alternative is something like row and col (or r and c), but i and j are again idiomatic enough that I don't think those are much of an improvement.)

Some people would use "n" instead of "person", but I would want to stay away from that.

I would also suggest that n is a bad choice; it sounds like it should be a count of objects.

Don't do this:

Agreed there.

[Anpheus]

You two do know that if you type // you can then type whatever you want after those slashes and it won't affect the code at all, right?

I mean, for all your complaints about variable names, it's really silly when you think about it, because there are always multiple ways to name a variable, particularly such a narrowly scoped variable that only exists for microseconds as a register then goes poof. I don't know, I agree those examples you gave of 'bad code' being bad code, but I think making it good code is as easy as adding some comments.

//m = mass, v = velocity

[heXiuM]

This was already mentioned before, but the key is consistency. If you're coding from scratch, adopt one convention and stick with it. If you're working on already existing code, follow the convention used. Never assume that you will be the only one working on your code or that you will never have to work on someone else's code!

Personally, I indent code with tabs and align them with spaces, but I've set the editor to convert tabs to spaces, so the end result has only spaces.

[EvanED]

You two do know that if you type // you can then type whatever you want after those slashes and it won't affect the code at all, right?

I also take the point of view that if something can be expressed in code, it should be. Why have it in a comment when you can just as easily put it in the actual code?

I mean, put it another way. Suppose that I had kineticEnergy(float m, float v); // m = velocity, v = mass. I'm actively trying to be confusing here by choosing very bad names deliberately. Does a comment make it all better in this case? If it doesn't, then why does it make it all better in the case where I'm not being deliberately confusing?

(I agree that a comment would help, I just think it would be better done in the names.)

[Anpheus]

If there's a lot of heady math going on involving physics or mathematics, I think using common symbols is absolutely fine. It makes the code easier to understand at a glance to keep symbols as short as the operators, easier to write down and work through on your own, etc.

[Tei]

Once code get complex, and you absolutelly must fix it now. Comments are life savers.
Code should be commented, like these directors comments on DVD movies. Help a lot!

[Hammer]

@Tei: Please post in the INTRO thread when you get a moment. Thanks.

[JayDee]

Code should be commented, like these directors comments on DVD movies. Help a lot!

Copious name-dropping and semi-random anecdotes? Could make an interesting read.

[phlip]

Copious name-dropping and semi-random anecdotes? Could make an interesting read.

Code: Select all

  /* Oh, I remember when I wrote this function... Knuth dropped by that day,
   * and gave me the idea, but he couldn't get it to work... and he didn't have long
   * to work on it, 'cause he was just passing through, on his way to the game.
   * But we kept at it, and this is the end result. I think it was definitely
   * worth the effort. Knuth's team won the game, 7-3. */

[_peterb]

I suggest a fork of this thread to one that discusses comments. I'll make one.

Having struggled around with spaces and tabs, I'm beginning to believe that whitespace should not be considered as syntactically important -only aesthetically, sorry python.

There's just too many problems with a standard that doesn't define something as important as the length of a tab. Personally I would prefer to see tabs stored as \n to avoid imposing a certain style on programmers, and because it is trivial to convert tabs to spaces, but not vice versa.

Having said that, it is much more convenient to work in spaces because then it's easy to zap rogue tabs.

In case anyone needs it, a one liner to do this on the terminal is:

Code: Select all

perl -p -i -e "s/\t/    /g" (filename)

ie:

Code: Select all

perl -p -i -e "s/\t/    /g" *.py

[_peterb]

Ok - theres a comments thread here: http://forums.xkcd.com/viewtopic.php?f=40&t=15522

[++$_]

I think comparing anything to Perl is an insult.

Sigh. Have you ever used Perl? Yes, you can make it into a nightmare if you want. You can also do that to C++. In fact, C++ is worse because there are fewer special characters serving as signposts. Well-written Perl is at least as easy to read as any other language, and sometimes more so, because the language gives you the options you need to write clearly.

EDIT (very late): It's possible to write Perl like Java. If you want to see how this works, ask a Java programmer to write something in Perl, and it will come out looking exactly like Java, except with extra $s.

As for the actual topic of this thread, spaces always. I used to not care but I discovered that some printer daemons don't print tabs properly (this was on OS X). So my code got garbled when I printed it out for an assignment. Now I use spaces exclusively.

[Anpheus]

Copious name-dropping and semi-random anecdotes? Could make an interesting read.

Code: Select all

  /* Oh, I remember when I wrote this function... Knuth dropped by that day,
   * and gave me the idea, but he couldn't get it to work... and he didn't have long
   * to work on it, 'cause he was just passing through, on his way to the game.
   * But we kept at it, and this is the end result. I think it was definitely
   * worth the effort. Knuth's team won the game, 7-3. */

My code from now on will be legendary.

"OH MY GOD, John Carmack helped you write this?"

"HOLY SHIT, how did you get Linus to contribute here?"

[Sollos]

I use tabs as it's much faster. Although being a high school student, it doesn't matter whether I use tabs, spaces, comments, or alt codes.

[Aperfectring]

I run into the problem at work that there are three distinct groups:

1. Three spaces (official coding guidelines policy)
2. Four spaces
3. Tabs

Unfortunately, many people will mix 1&2 in the same file, making it impossible to actually determine what code actually lines up without using IDE tools, or re-indenting the code. Through rigorous training, I have trained myself for 3 spaces indentation.

[segmentation fault]

set tabstop=2
set expandtab

this will make tabs with a length of 2, and those tabs will be spaces, so if you open them up on a different platform, they will appear consistent.

YAY!

[enk]

set tabstop=2
set expandtab

this will make tabs with a length of 2, and those tabs will be spaces, so if you open them up on a different platform, they will appear consistent.

YAY!

set tabstop=8
set softtabstop=2
set shiftwidth=2
set expandtab

what you said above plus other peoples files will appear consistent!

[Arancaytar]

I configure all my editors and IDEs to set tab width at 2 spaces (for those files which contain them, which aren't mine), and to use 2 actual spaces for indenting my own code.

I couldn't care one bit less whether tabs are 2, 3 or 8 spaces wide. I do this to get internal consistency with the standard I need to comply with most often, which is the code style for Drupal.

[Xanthir]

Taking this back to tabs vs spaces...

I use tabs. I hate spaces. I want to kill people who use spaces.

Spaces for alignment, after tabs have been used to indent? I can stand this. However, in my own code, when I need to break a line I just indent it one more level. It doesn't match up exactly unless I get lucky, but it's close enough that I can easily tell what's going on.

Also, my text editor will tab entire blocks of code if I highlight it, which is useful!

[Arancaytar]

Mine does the same, except that it prepends two spaces to all highlighted lines when I press tab. Very useful too, and you don't notice the difference.

Seriously, if the editor takes care of auto-indentation anyway, there is no reason to use a character that doesn't even have a defined width.

[enk]

Seriously, if the editor takes care of auto-indentation anyway, there is no reason to use a character that doesn't even have a defined width.

It has a defined width (or max width, if you want) which is 8 spaces. And if you display ASCII nines as two spaces, it will look different in another guy's editor (and on line printers ).

On the other hand, it might be a good idea, as people can easily change tab display width. This takes more consideration if spaces are used for indentation.

[endolith]

Elastic tabstops - The solution to the tabs-versus-spaces issue

No, comments are not meant to have images and links, thats what documentation is for.

What a ridiculous attitude. Why flip back and forth between multiple documents to follow the code?

http://en.wikipedia.org/wiki/Literate_p ... nterpreter

[EvanED]

Elastic tabstops - The solution to the tabs-versus-spaces issue

For some strange new definition of the word "solution".

His site and video only cover the somewhat easy cases, and arguably not perfectly. (For instance, note in the video how at 1:28 how the comment on line 11 doesn't move.)

I tried his Java demo, and went for another common example of when you often want to align something:

Code: Select all

  cout << "Line one of output\n"
       << "Line two of output\n";

Hmm, a tab doesn't correctly align the <<; it looks more like this:

Code: Select all

  cout << "Line one of output\n"
          << "Line two of output\n";

Or sometimes you want to indent the second line of the condition in an if statement. Oh dear, that doesn't really work either:

Code: Select all

  if (x >= minX && x < maxX &&
          y >= minY && y < maxY)
  {

I guess I'm back to using spaces to indent those second lines.

The problem is that the problem he's trying to solve is no easier than trying to create a tool that does global indentation the way you want. Which is an extremely difficult problem. If you had a solution to that which worked if there were tabs in place, I could give you a solution to it which uses your solution, but work for arbitrary indentation, and I would put far far less effort into it than you did.

For something as free form as C-like languages are, you're not going to have an automatic indentation tool that will make most people happy.

[phlip]

Code: Select all

  cout << "Line one of output\n"
       << "Line two of output\n";

I think the idea is that you'd do something like

Code: Select all

[tab]cout[tab]<< "Line one of output\n"
[tab][tab    ]<< "Line two of output\n";

They line up if you do that.

Code: Select all

  if (x >= minX && x < maxX &&
          y >= minY && y < maxY)
  {

Again:

Code: Select all

[tab]if ([tab]x >= minX && x < maxX &&
[tab][tab    ]y >= minY && y < maxY)
[tab]{

However, since "if (" is so short, this comes out looking ugly, with a big gap between the if and the actual condition... in fact, even when it's not so short, like it is in the function header for someDemoCode, it's still got an (admittedly less) ugly gap there.

Also: anyone who claims that being able to use proportional fonts for coding is an advantage loses my support... but that's a separate religious war there.

[Rysto]

Code: Select all

  cout << "Line one of output\n"
       << "Line two of output\n";

I think the idea is that you'd do something like

Code: Select all

[tab]cout[tab]<< "Line one of output\n"
[tab][tab    ]<< "Line two of output\n";

They line up if you do that.

Not if you set your tabstop to 2 or 3.

Edit: Or 4, for that matter.

[Anpheus]

You're not paying attention to the conversation, they're talking about this elastic tabstops tool for GEdit.