Tabs vs Spaces


As I see it there are three camps, each with a decreasing level of wrongness.


First camp:
Only tabs.  This is about as wrong as you can get.  Start with:
class MyPen
{
<tab>public void Method1(int i,
<tab><tab><tab><tab><tab>string s)
}

That’s pretty useless.  Go to someone who doesn’t have 5 deep tabs (say 8) and you’ll get

class MyPen
{
<tab   >public void Method1(int i,
<tab   ><tab   ><tab   ><tab    ><tab   >string s)
}

Wrong wrong wrong.  Alignment is totally destroyed


Second camp:
Only spaces. Still wrong, but not as bad as all tabs.
Start with:
class MyPen
{
........public void Method1(int i,
............................string s)
}

Now go to somebody who really hates deeply indented code and wants thinks only indented 2 deep instead of 8 deep?  What can they do with your code?  Nothing!  This sucks.  Code is rarely owned by one person.  Many people need to work on it and understand it and forcing your view of how it should look on everyone can make that a more difficult task.


The solution?  Well, we could try to merge the best of both worlds.  Use tabs for indentation and spaces just for alignment.  That would give us the third camp:
class MyPen
{
<tab   >public void Method1(int i,
<tab   >....................string s)
}

Then someone who likes small indents would see:

class MyPen
{
<>public void Method1(int i,
<>....................string s)
}

This is certainly the least wrong of the three camps.  It allows for alignment to not be destroyed, while giving flexibility to anyone who views it to see indentation the way they want it.  Many would argue that that is the best we can do.  tabs are meant for indentation and spaces are meant for alignment, so as long as you use them that way then you’re doing the best you can.
I disagree with that sentiment.

The real issue here is that in most programming languages (i’ll leave out Python and Whitespace since they’ve mostly eliminated this issue) is that whitespace is pretty irrelevant.  The difference between a clump of whitespace and one single whitespace is almost never relevant, and the difference between any whitespace and no whitespace if often not relevant.  Because of that, many people have fun with whitespace and cross the zero/one/infinity boundaries in order to make their code look good to them. 

For example, i find the following mostly unreadable:

class MyPen
{
<>public void Method1(int i, int j,
<>....................string s)
}

I can only really deal with all parameters on one line, or each parameter on a different line.  However, if we only pay attention to tabs and spaces then when i open this document I will still find it illegible. 


So I’m of the 4th camp:
Whitespace might be part of the actual ‘data,’ but when I’m dealing with editing it present it in a ‘view’ that looks right to me by passing it through the formatting ‘model’ that knows how I like things to work.  When I save, some set of group rules will decide the form it is saved in.  So when i look at that method above I see all the parameters on different lines, when you look at it you see it you’ll see all the parameters on the same line, and when that freaky girl over there looks at it she’ll see it written as above.  

This need not affect any tools or experience of yours.  Say you’re debugging; the debugger will know the actual location in the code where your current statement is, it then passes that span to the view which automatically remaps that span to the view I currently have in front of me.  It’s a totally transparent operation to every tool currently out there because it’s just a layer that sits between me and the current final view layer. 

Can we do this for the next version?   Can we unify the concepts of “team settings” and “user settings” so that you the developer can work with code in the best way for you while not impacting your peers from developing in the best way for them?  I don’t think we can for everything, but i think we certainly can in this area 🙂 


Comments (56)

  1. Jim Bolla says:

    Then there’s those of us who use variable width fonts. 🙂 Once you get over the ingrained pixel-naziism, its much more readable and natural to work with.

  2. Joe says:

    I used to be in the all spaces camp, until I realised that the only IDEs I use any more all have a tab size of 4 and anyway have an option to easily Tabify/Untabify sections of code.

    Now I don’t care any more and prefer to leave existing code in its original format, especially because I don’t want file comparison tools like Windiff or my Source Control system to show up spurious differences.

  3. Sean Lynch says:

    All the line breaks are wrong, the comma is at the end of the parameter. Of course this comes from doing lots of sql cursors and declarations.

    I do like this idea, since I believe the only correct answer is that one that just has me pressing Enter. So right now:

    class MyPen{

    <tab>public void Method1(int i

    <tab><tab>,string s)

    }

    is the right answer to me, since its not really worth the extra work.

  4. For some reason, I can not stand line-breaks like that in C#. The only thing worse than extra line breaks in C# is when an xml element is split up with a new line for each element (see web.config files for an example). It’s a "line" of code, not a paragraph. 🙂 Those linebreaks make me think of code that was wrapped so it would fit onto a web page. And then copy&pasted into a project without being reformatted.

    However, I have OCD when it comes to formatting T-SQL inside a stored procedure. You’d think e.e.cummings wrote some of my procs.

    I also prefer to use the default bracket arrangement in C# in VS.NET but do it differently in JavaScript and a third way in ActionScript. It just doesn’t look right to me otherwise.

    I agree with you about the third manner (spaces & tabs), but since I try to never have those extra breaks, there is little to no need for the spaces (except in my procs, where I err to the left).

  5. Todd says:

    Yes, somebody else who breaks *before* the comma rather than after! I love that method, because if you need to add a new parameter it’s completely obvious that you have to also add a comma. Breaking after the comma not only leaves you in an ambiguous state where you have to inspect the previous line to determine whether or not you need a comma for your new parameter, but it also has the potential to turn a single-line change in a file into a two-line change, making it less clear in windiff what the actual change was.

    I also learned this habit from T-SQL programming, and carried it over into other languages I use. I wonder how many of us pre-comma line-breakers learned this from T-SQL or from someone who learned it from T-SQL?

  6. Aaron Robinson says:

    If whitespace really doesn’t matter, you could entirely get rid of the parameters on the same line as the method declaration, such that you don’t have to worry about aligning to an arbitrary depth based on the number of keyword modifiers and length of the method name:

    class MyPen{

    <tab>public void Method1(

    <tab><tab>int i,

    <tab><tab>string s

    <tab>)

    }

  7. Aaron: that’s absolutely right. You could indeed do that.

  8. Todd: Sounds like windiff sucks if it only does line based diff comparisons!!!

  9. Radu Grigore says:

    My first reaction was: "why would anyone spend time with such problems (tab/space) instead of trying to solve real problems?". Then I realised that sometimes, when I’m forced, I do it too. I’m forced when I need to read some code that I find aesthetically unappealing. It takes my attention away from the real problem.

    IMO the real question is how should we avoid such situations of "attention stealing":

    1. Should we have an underlying representation of the content of the code (say XML) and let the aesthetics be somewere in a "user preference" file?

    2. Or should we all (at least all from a team) follow some common aesthetic guidelines?

    Cyrus, you are obviously for the first solution. To make it work I’d start by taking a closer look at technologies created for disentangling content from presentation (such as html/css) and then either use one of the existing technologies and apply it for code or invent something new, which uses the good ideas of existing technologies. I’m by far not an expert in such technologies but XML/XSL and some sugar on top of it sounds to me like it might do the job.

    But there is a second option. It is very hard to get people to agree on code aesthetics. In other fields I think that we can safely say that there is a "feeling" in the community about what is "beautiful": we mostly agree about if a women is beautiful, mathematicians mostly agree if a theory/proof is beautiful, etc. Why shouldn’t programmers mostly agree if a piece of code is beautiful?

    In short, even if the technology will eventually allow every programmer to see the code as he likes, I still think that some common ground is needed. After all, from time to time two programmers need to work on the same monitor.

    With this in mind, I’ll say that wether one uses tabs or whitespaces is kind of irrelevant. It’s still whitespace and as long as things are nicely indented everything is fine. I don’t care if things are indented because of tabs or because of spaces. Well, actually I do, but only because my editor doesn’t already have the feature suggested by Cyrus. But, even if such a feature is implemented, I would still care about things like: how many nested loops are, how far is a declaration from the first usage of that variable, etc. I.e. the common ground for what is beautiful can be moved to a higher level of abstraction if Cyrus stops talking, starts coding, and implements this great feature he presented.

    I can’t wait to see it 🙂

  10. Radu Grigore says:

    Aaron, yeah.. that’s mostly how I write code too..

  11. I prefer the style from Aaron Robinson’s post. That is how I do indentation if I have to put each var on a different line.

    But I tend to only do that if I have lots of arguments or the call goes past 80 chars. For something really small like your Method1 I would leave it on one line. Otherwise it is too hard to fit an optimum quantity of code on one page.

  12. Dan Golick says:

    I like to use tabs to indent with a tab Size of 4 and an indent size of 4 but have my options set to Insert Spaces. This ensures that if someone opens the code with tab size not set to 4 they will see properly indented code.

    Really the use of the tab is just a convenience to get what I’m typing to the correct indentation level. If I need to work on someone elses code (and who doesn’t?) I may run it through a pretty printer to read it but I try to leave the formatting alone when I check in so that differences are isolated to the changed lines.

  13. AT says:

    I believe that source code is not simply a text with characters, whitespaces and tabs. But it’s an representation of your ideas.

    Just like Microsoft Word will use different paper sizes then printing same document on different printers, you must use different identation for source code based on person prefferences.

    It can be possible to create two-level system, one settings for source code is the way it’s stored in source control system, another setting is how developer willing to see this code. And IDE must perform conversion beetwean thouse two representations.

    It can be hard to keep dynamicaly formatted plain-text in source control system, so I preffer SCS keep something like a parsed tree of source code and commit changes on method/class/documentation element level.

    This way if one of developers decide to rearrange methods without changing their code – SCS will understand this and do not show you long 500+ lines difference.

    Source code formatting will be based on how person willing to see them. As result there will no any problems with <tab> are 1 character, 4, 8 or 32.

    Additionaly people will be able to select how to show arguments, on one line always, or each argument on new.

    Even such a lame trick like showing one-statement after if can be a an option.

    "if(true) return false;}" vs. "if(true) { return false;}"

    Keeping sources and their difference in computer readable (not plain text) format can allow a lot of others cool things like a version control for UML and class diagrams. You will be able to query for revisions on method basis and see that functionaly realy changed beetwean two versions.

    Representing source code visualy (not plaint text, again and again 😉 can provide a lot of benefits (if implemented correctly).

  14. Steve Perry says:

    I’m of the camp that does not like to break parameters across lines. I spend far more time looking a lines of code than a single line, that I want as many lines displayed at once as I can get. I normally know what that one line of code is doing by looking at the name of the function, I don’t care about the parameter, I normally assume (bad) that the parameters are correct, unless a bug is traced back to that specific line, then I will examan the parameters carefully.

    I do agree that TSQL is different and I break each parameter of a stored proc on its own line (only when defining the stored proc, not calling it). I also tend to break select statements on the select/from/where portions.

    My 2cents

  15. Todd says:

    Windiff has its share of problems, but the diffing engine is usually decent. However, I’ll illustrate what I was talking about with images:

    post-comma line-breakage: http://www.daishar.com/images/diff1.jpg

    pre-comma line-breakage: http://www.daishar.com/images/diff2.jpg

    The first diff is 3 lines (1 old, 2 new) of differences, because the old line had no comma. Looking at this, it looks like a lot more has changed than is really the case, and makes you have to at least look at the changed line to make sure that nothing more was changed but the comma. This diff is "busier" for no good reason.

    The second diff is exactly 1 line, the line that is changed, because that line contains everything it needs. The comma is included on the line, so when you look at the diff you see what really happened — a single line was added, nothing else was changed. Clean, elegant, and to the point.

    Diffing’s not the only reason I prefer pre-comma line-breaks, either. Especially for new programmers, forgetting to add a comma on a change like this is a big possibility, leading to breaking code. By breaking the line before the comma rather than after, it’s clear that new additions will 1) need a comma, and 2) that comma needs to be provided by the developer making the change.

  16. Slusky says:

    You should have a look at GNU indent, assuming you haven’t already. <URL:http://mysite.wanadoo-members.co.uk/indent/beautify.html&gt; Basically it tokenizes C source code and then wraps and indents it according to user-specified parameters.

    Hey, maybe you guys could even patent it. 😛

  17. froz says:

    Timely post- I just got reprimanded this afternoon for using tabs&spaces instead of all spaces. Reason gave was because people view code in alternative editors that do 8space tabs (notepad etc.). I’ve been stewing all afternoon about how dumb it is.

    I especially hate how spaces interact with commented code. When commenting out 1 line of code I do the comment at column 0, when commenting for documentation I do it at start of text. Spaces screw up the column 0 code comments.

  18. Froz: send them to this page then 🙂

    That should clear up the entire issue.

  19. Slusky: Is that the real slusky??

    From teh site:

    NOTE: Indent is designed to support the C language. It is NOT, repeat NOT, designed to work with C++. It may work with some C++ code but you are on your own: usage of indent on C++ is not supported, so DO NOT complain if it doesn’t work on your C++ code.

    Craptastic software. Plus, it’s not clear how it would deal with teh debugging scenario i outlined above.

  20. DrPizza says:

    "Can we do this for the next version? Can we unify the concepts of "team settings" and "user settings" so that you the developer can work with code in the best way for you while not impacting your peers from developing in the best way for them? I don’t think we can for everything, but i think we certainly can in this area 🙂 "

    But can you do it right?

    It would require the formatting engine to be able to turn the canonical layout which it’ll presumably store (as we don’t want checked in versions thrashing between styles depending on who checked them in last) into an arbitrary per-user layout. PDBs and things will all refer to this canonical form, and it’s what "dumb" editors will check out (so the canonical form must itself be configurable).

    At the moment it can’t even manage mixed tabs and spaces properly. Anonymous delegates (or inner classes, in Java) make this even harder, as they require code to go "tabs spaces tab spaces non-whitespace" which no tool AFAIK can currently handle (you can just about get tools to work with tabs followed by spaces followed by non-whitespace).

    You also have more complicated issues, like what to do with comments. If someone uses the ghastly "parameters on multiple lines with // comments after each to describe it" style, which seems quite common, what should you do with the comments? I don’t want them turned into /* */ (because my formatting rules would eliminate all /* */ because they’re dangerous). Where should they be stuck? Perhaps they’d get put into a header. But how would that process be reversed? They’re not annotated with XML documentation tags (nor should they be, if the original developer did not do so), so if I were to add a parameter and a corresponding piece of documentation, there’d be no way to reverse the process and give back the original developer the layout he wants. And even if we did use XML documentation, he might do the same for a function *call*, and there’s no way to annotate parameters with XML documentation at call sites anyway.

  21. DrPizza says:

    "Then there’s those of us who use variable width fonts. 🙂 Once you get over the ingrained pixel-naziism, its much more readable and natural to work with. "

    Which fonts don’t look like complete crap when you use them? Which properly distinguish punctuation and other confusable characters?

    Monospaced fonts have a lot more scope for reducing this kind of ambiguity.

  22. Dr.Pizza: "It would require the formatting engine to be able to turn the canonical layout which it’ll presumably store (as we don’t want checked in versions thrashing between styles depending on who checked them in last) into an arbitrary per-user layout"

    Of course. The ‘model’ wouldn’t be one way. It would format for the user in one direction and for the team in the other.

    "At the moment it can’t even manage mixed tabs and spaces properly"

    With this system it wouldn’t have to.

    "Anonymous delegates (or inner classes, in Java) make this even harder, as they require code to go "tabs spaces tab spaces non-whitespace" which no tool AFAIK can currently handle (you can just about get tools to work with tabs followed by spaces followed by non-whitespace). "

    Again, this isn’t necessary in this system.

    "You also have more complicated issues, like what to do with comments. If someone uses the ghastly "parameters on multiple lines with // comments after each to describe it" style, which seems quite common, what should you do with the comments?"

    This breaks the model i discussed where 0/1/many whitespace doesn’t matter. With // comments whitespace is relevant because a line separator ends the comment. You could not remove whitespace in that case.

  23. Slusky says:

    Yeah, it’s me, in the flesh.

    I’d agree that GNU indent is limited (tho’ I’d stop short of "craptastic"), but the principle applies very well to your problem. If you’re in an IDE, there’s got to be a tokenizer close at hand&#8212;use it, and then apply per-user indent settings before presenting it to the user. Debuggers could work the same way.

    Before checking the code back in to a central repository, apply some respectable default settings so the version-to-version diffs look decent.

  24. Thanks slusky for repeating what i just said above 😉

    Hehehe. Good to hear from you!! IM me sometime

  25. Darren Oakey says:

    ha – looking for a religious debate? 🙂

    In the perfect world, I’d be in the fifth camp. I think whitespace should be reasonably irrelevant to the syntax, but adds a lot of benefit for the presentation… to my mind, there’s no good reason why we should have a choice of what standard we prefer – one piece of C# code should look like another. I always loved VB in that respect – when you hit return on a line, it goes and adjusts your whitespace for you. To me, that’s what should happen across the board. It should just be automatically inserted and maintained by the compiler.

    However, given the perfect world ain’t quite here yet, I’ll step up to the forefront of the "kill all tabs" parade (maybe not as far as… all users of tabs…. maybe :))

    The thing is, tabs would be fine if they were the only way of putting indents in. But they aren’t. You can hit space. And you can’t tell the difference. And in 100% of cases (making up statistics again) you end up with a bizarre mix of tabs and spaces.

    Which becomes horribly apparent as soon as you want to print the code, paste it into a document, do a diff, load it into another editor, put it on a web page, or interact with it in any way other than the ide. It’s not just that tab sizes differ, but also proportional fonts change the spaces per space ratio dramatically, and lines which used to be nicely aligned are suddenly nowhere near each other.

    I would offer the proposition that there is no reasonable way of enforcing users to always do the same thing with a mix of tabs and spaces – and that if a mix of tabs and spaces is allowed in a document, you will always pay for it in a negative way at some point in the future.

    Now, obviously, banning the space character is going to be a problem, so the only conclusion is that chr(9) has no place in our code!

    TABS….. JUST SAY NO!

  26. I’ve been in the "all spaces" camp for awhile, mainly because I have processed source many times with perl scripts and the like. If tabs are out of the pictures, there’s exactly 1 way to indent N columns – N spaces. When tabs are allowed, the number of possibilities goes up tremendously, and post-processing becomes more of a PITA.

    I see tabs as being an anachronism from the same days that led Bill Joy to pick the command set of vi keys – it doesn’t make it evil, but I don’t consider it optimal either 🙂

  27. Spaces only, everything else is just wrong! 😉

    But speaking of this, is there any way to get VS AutoFormat to line up function arguments correctly — i.e. the way you have listed in your blog? I hate how VS simply indents four spaces by default.

  28. All tabs here. If you don’t know how to set your tab preferences to 4 spaces, you are a dumbass and shouldn’t be reading my code in the first place.

  29. Just one question:

    If we all have our own code-layouter-er, what happens when i send an email to the guy down the corridor saying that the code crashed on line 579 of <filename>.[vb/cs] and he goes and debugs a different line of code to the one that i’m seeing?

    –Geoff

  30. Matthew W. Jackson says:

    I prefer tabs, because they ARE tabs!

    As for lining up things with spaces, that’s fine by me, but the general indentation should be tabs. If I continue a line, I use a single tab for a hanging indent.

    Using spaces in code is just as bad as using spaces to line things up in a word processor. And I’ve put up with enough of that crud when editing other people’s documents to not want to put up with it from programmers who should know better.

    Using tabs makes sure the indentation works no matter what the tab size, and no matter whether proportional or monospace fonts are used.

  31. kristof says:

    It would be very nice if source code was persisted in XML (pure data, no markup). Every developer could create a stylesheet that depicts how he likes his sourcecode rendered on screen. You could also render the source in a more graphical way (not pure text).

    But then of course, the persisted files would not be C# anymore. And it would be practically impossible to edit the files without a good editor (as opposed to notepad or Emacs – do I hear Don Box complaining in the background?)

    This is what happened in the rest of the IT world: there is a clear distinction between how a file is persisted, and how it is presented to the user. Nobody is editing bitmaps, music files, excel sheets etc… directly in its raw format. But that is exactly what we programmers have to do.

  32. Radu Grigore says:

    Geoff, you don’t… You write an email saying that the code crashed inf functtions "Bau" at _statement_ 5. The editor should help you with identifying that place easily.

  33. James: That’s a pity. You’re enforcing your view of the code on other people who want to read it 🙁

    Indentation is something that people want to view differently and tabs are meant just for that. By not using something for it’s natural purpose you prevent those who want to see something indented to a level that’s nice for them.

    They will have to replace all of your indent spaces to do just that.

  34. Tony: Talk to Kevin blogs.msdn.com/KevinPilchBisson he owns the whidbey C# formatting engine.

  35. Richard: All-tabs is horribly broken.

    The *reason* that tabs exist is so that people can arbitrarily decide what indentation level to set it at. The notion of "all tabs and each tab is 8" is a misuse of the feature. If you only use all tabs then alignment is no longer possible.

  36. Geoff: That’s an excellent question. That runs into a problem of "Strings are smelly". You shouldn’t have to send that information. You should just be able to drap and drop the crash/callstack/whatever to him. That object will have the actual line/col of the problem and his software will translate that into his coordinates.

    Of course, i realize that that’s a fantastical mystical future, and what you’ve raised is a definite issue…

    How about a simpler one: what happens when your coworker comes to your office and tries to help you debug through a problem when your code is formatted in a way that makes his brain hurt?

    We have that issue in our team right now.

    I like:

    Foo() {

    my peers like:

    Foo()

    {

    If I code in the first manner they literally have trouble understanding the code because their minds are so used to looking for {‘s in a certain location and if they don’t see it there it gets quite confusing.

  37. Kristof: That’s a possibility. However, there is one issue:

    How do you deal with unparseable source code?

    What i mean by that is this: if you have parseable source then there is a 1<–> 1 mapping between that and a well formed parsetree and then a 1<–>1 mapping to a nice structured xml doc. However, once the source becomes unparseable then you need a way to represent that.

    It’s not a huge issue, but it is one that needs to be taken into account. In both forms you need to pay attention to the indentation and whatnot and preserve them.

  38. DrPizza says:

    "With this system it wouldn’t have to. "

    Yes it would. If it’s to format for the user or the team properly, yes, it would have to.

    "Again, this isn’t necessary in this system. "

    Yes it is.

    "This breaks the model i discussed where 0/1/many whitespace doesn’t matter. With // comments whitespace is relevant because a line separator ends the comment. You could not remove whitespace in that case. "

    Nor does /* */ vs. //. They have the same semantics; comments mean nothing to the program. They should be switched according to user preferences just like whitespace should be.

  39. DrPizza says:

    "How do you deal with unparseable source code? "

    You don’t let people check it in, so don’t need to normalize it or reformat it.

  40. Dr.Pizza: You are confusing/extending the issue here. We started with a tool that would lexically modify the progam keeping the semantics the same.

    It is natural to extend that to a tool that would modify the parse tree while keeping the semantics the same: for example, a tool that would reorder methods for you according to the way you like it. It’s also natural to extend this to a tool that would modify the expression system but would keep the semantics teh same: for example, rewriting boolean expressions according to a form you saw fit.

    However, these enhancements aren’t what’s being discussed. This whitespace transformation would not have to be aware of them. You could have many layers of transformation that would take teh "team source" and turn it into "your source" and back again. We could talk about those in the future, but their inherent issues do not affect this transformation.

  41. DrPizza says:

    "However, these enhancements aren’t what’s being discussed. This whitespace transformation would not have to be aware of them."

    They can’t be separated. Parameters on newlines is a whitespace issue. But fixing the whitespace issue brings up a comment issue.

    If on reformatting the tool left parameters broken over several lines alone, it would be no use. It must fix them, because it’s a whitespace normalizer, and they’re highly abnormal whitespace.

    "You could have many layers of transformation that would take teh "team source" and turn it into "your source" and back again. We could talk about those in the future, but their inherent issues do not affect this transformation. "

    And again we still have the problem that even for this transformation, transformation tools are unfortunately all too stupid. Especially if you *do* want to handle broken parse trees.

  42. Gavin Morris says:

    I’m in the all-spaces camp, have always been. Worse than that for you 4-column-tab guys, I set tabs to 2 columns.

    Cyrus: I’ve been wishing for an IDE capable of source-code-in-database (or XML) for a loooooong time now. In particular I want to be able to render the comments, documentation and code separately. I’ve looked at the implementation a little, and the number of issues make the implementation … interesting. Is anyone on the VS team interested in that type of functionality?

  43. Gavin: of course we’re interested 🙂

    Could you talk more about the issues? I’d love to hear them. Feel free to post them here to use the "contact" link to get in touch with me directly.

  44. Cyrus, if you only use all tabs, you are always aligned correctly. A tab is a tab. 2 Tabs is 2 Tabs. Each line that is 3 tabs from the left in Notepad are lined up correctly with each other in Notepad and correctly lined up between everything that is 2 or 4 tabs in. When you move to another editor, everythign is still lined up correctly. It only fails when you break a line before the end and break the rules of nested indents. That messed up line may be in the wrong place but that’s only because it isn’t a line, it’s part of the line above it.

    If everything inside a set of brackets is 1 tab further than the brackets, there is a logical, natural order to the code that works no matter what editor it is in.

  45. Shannon: That’s not true. Take a look at the first case above. If you go into another editor your tabs will end up making your code unaligned.

  46. DrPizza says:

    I think essentially he was proposing that you never use alignment anyway, only indentation.

    I don’t think it’s even close to optimal, but he’s right in claiming that it doesn’t ever "break".

    I wish VS.NET could (somehow) maintain alignment when using bold. I embolden symbols but it throws out alignment by a pixel or two for each symbol. Very annoying.

    And please, please, please, please, PLEASE:

    REMEMBER THAT I HAVE VISIBLE WHITESPACE ENABLED.

    ffs!

  47. AndrewSeven says:

    class MyPen{<tab>public void Method1(int i, <tab><tab><tab><tab><tab>string s)}

    This example is problematic, the number of tabs before the string s is a function of the length of the method name.

    I stopped doing that because I would have to change all the tabs when I changed the name.

    At present, when I feel need to put the parameters on the next line, I add only one tab.

    class MyPen{<tab>public void Method1(int i, <tab><tab>string s)}

    I can’t see why on kind of statement continuation is different from annother, you wouldn’t indent the {} more because the class name is long 😉

    When I have parameters on new lines, I feel bad, it smells bad, there are too many parameters or maybe my screen is too small.

  48. Cyrus, if you mean the first example in your post, then you don’t understand what I said.

    " It only fails when you break a line before the end "

    The "string s" part should not be a new line. It is the end of a line of code, not a line of code.

  49. Jim Clark says:

    This whole conversation cracks me up. It is such a typical "programmer" argument 🙂

    I used to use the tab, space method for alignment. This way the alignment always worked. I took off my code-reading training wheels a long time ago so I don’t need to waste 4 spaces with each tab, so I set my tabs to 2. Those on my team that still need a lot of white space could set their tabs to 4 or 8 and everything would still line up.

    But for many people that style is too much effort so you end up with a mix of styles. So I converted to the tab-only crowd and discarded "alignment" as a waste of time. This works fine once everyone becomes accustomed to it.

    Of all the reasonable choices the space-only choice is the worst and indicates a higher than average degree of inflexibility on the part of the developer 😉 In case you are wondering, tab-to-align is not even a reasonable choice. If you are doing this your code looks ridiculous to anyone using a different tab size.

    I like to put these things up to a vote and force everyone to use the agreed upon method. More important that who is "right" is that everyone on the project use the same style.

    Of course that’s just my opinion, I could be wrong.