If you use spaces instead of tabs, you're never relying on a particular editor or pager to have tab width set correctly.
Tabs aren't just used at the beginning of lines. There might be a left-aligned, multi-line comment to the right of a block of code(...)
I cannot fathom what point he thinks he's making with these. If you're using tabs in a way that depends on tab width, you're doing it wrong.
Tab indentation generally means that one tab character is one layer of indenting. That's it. It's about semantic structure, not layout.
If you want to make ASCII art, or align things like paragraph-style comments, or "indent" things that aren't part of a block of code like pieces of a lengthy conditional clause split over multiple lines, use spaces instead (and then the five people who use proportional fonts will complain that using spaces for alignment "isn't portable"). Of course, if you're using a language with an off-side rule for syntactic whitespace even a die-hard tabber ought to just use spaces.
Personally, I dislike that sort of non-semantic formatting business in source code (and I think off-side rules in syntax are a horrible idea), but that's a matter of taste. And obviously, consistency is vastly more important than the particulars of indenting style. But I get tired of people arguing against tabs on the basis of not knowing how to use them properly.
On the other hand, this unintentionally makes a different, very strong argument in favor of using spaces: people can't manage to use tabs properly, so don't let them. This is why we can't have nice things, folks!
Oh yes. Tabs or spaces in source code. That's really what makes software great.
Just have guidelines and stick to them. What sucks is inconsistency.
Everybody's got an opinion about code layout. It doesn't matter. There's no good or bad layout. Readability is just another word for "looking like stuff I'm used to read".
What's interesting is that I never used to care how code was indented, never bothered me. However, I got a job using Python/Django, and almost all of the code in that community is in the PEP8 style (4 space indents, etc, http://www.python.org/dev/peps/pep-0008/).
Now whenever I read python code that is outside of PEP8 just a little bit, it makes me cringe, but I can still read other, non python code indented almost any way. Thought that was interesting.
Why don't IDE's just do the conversion on the fly on a per-user basis?
Sure you'd need to know the standard occasionally but can't the code just load with my "stylesheet" and then use tabs. Then when it's saved the code is simply reverted to space delimits. This sort of formatting issue should not be an issue anymore surely?
To be fair, this is partly because python is uniquely sensitive to whitespace issues. Other languages don't tend to care as much. C code that's mixed between 2, 4, and 8 space indentation might be untidy, but it's really not that big a deal to read it as long as the code isn't broken in other ways.
This is especially true when multiple developers have been editing the same file. Some developers will use tabs some spaces. The end result is code that is completely unreadable and that must be manually re-indented. The developer that uses tabs that is editing a hard space indented file, might not even realize what evil they are introducing to a file. Then the next developer opens the file and screams.
1. Interesting that both this and the opposing article were submitted by the same person (which suggests to me that the "I" in the article titles does not refer to the submitter).
2. Sometimes I use tabs. Sometimes I don't. I can never really remember, because Vim is set to :expandtab for me on some of my machines. What I do know is that I never really care.
I use the ^T, ^D, <<, >>, and = commands to shift my left margin around in Vim. I haven't typed a space or a tab at the beginning of a line in years. After all, why use low-level functions when you have high-level ones?
"It's less portable, since different editors/pagers render a hard tab as varying numbers of spaces, and most editors can have this number altered on a per-user basis too. If you use spaces instead of tabs, you're never relying on a particular editor or pager to have tab width set correctly. Even if you're prepared to configure every editor/pager/platform combination you use, aren't you going to be making life difficult for others who want to read or modify your code?"
Nearly every editor I've used allows you to adjust tab size. In my mind, that means tabs allow every user to set the width that they prefer.
"Or consider someone who is on an 80x25 terminal"... ok now where are just getting silly. This discussion isnt even really technical but more of a aesthetic opinion. A single standard would be best but it wont happen because it really doesnt matter as long as the code runs and your coders arent actively making text-pictures. Also that free BSD example is only because they have the time to format their comments like that. No one really comments like that , its unnecessary and if it causes problems then a simpler form should be used.
No one really comments like that , its unnecessary and if it causes problems then a simpler form should be used.
I comment like this. It's also not hard to do. You type something like:
some line of code ; here is my comment, blah blah blah, very long, blah blah blah
Then press M-q ("fill-paragraph"), and Emacs turns it into:
some line of code ; here is my comment, blah blah
; blah, very long, blah blah blah
Sometimes this looks nicer than:
;; here is my comment, blah blah blah, very long,
;; blah blah blah
some line of code
Anyway, both styles are quite common.
"Or consider someone who is on an 80x25 terminal"... ok now where are just getting silly.
I always consider people on 80 column terminals, because although I have a huge monitor, I would like to display more than one file at a time. Aiming for 80 columns means that you appeal to the "lowest common denominator" and it means that you can have lots of files within easy visual reach. (I actually end up near 90 at home and 85 at work... but I try not to exceed 78 too often.)
why would you call this trolling? the submitter's history indicates he is participating here in good faith. and i think the idea of finding two articles espousing diametrically opposed ideas and submitting them both is pretty clever. further, the conversations generated seem to indicate that people here want to talk about this constructively.
It's understood that one thread serves as channel for communication, so a discussion can take place between both sides. A second thread only dilutes the conversation; there are no separate parliament houses for separate party members, they all share one.
If I came across an opposing view, I would typically submit it in a comment/reply, not start a separate thread. And if you look at the topic IDs, they were submitted right after the other (i.e. submitter knew of both sides before hand.)
That, and the triviality of the subject made be suspicious of the submitter's intentions. I didn't mean to be hurtful, but, for crying out loud ..
there are certain evergreen topics here that are always going to lead to heated debate. iphone versus android versus pre, mac versus windows versus linux, rails versus drupal versus php, ruby versus python versus c++ versus perl versus lisp, etc etc etc.
each time an article is posted here that takes a stand one way or the other, it prejudices the resultant discussion. it's sort of inherently understood that, if you want to comment strongly anti-iphone, you better wait until the posted article itself is also anti-iphone, or else you're going to face stiff opposition and downvotes.
by posting two articles, one pro-tab and one anti-tab, the submitter has neatly sidestepped that problem. if news.yc tilted strongly one way or the other, you'd expect one article or the other to get most of the upvotes, and the other one would sink. as it turns out, both articles have been running neck-and-neck for hours. interesting. it shows that tab lovers and haters exist here in equal proportions, which i really wouldn't have guessed.
"each time an article is posted here that takes a stand one way or the other, it prejudices the resultant discussion."
Wouldn't a good thing to do in such a situation be to write an article of one's own summarizing the key points from both the pro and anti arguments, titling it something like "To tab or not to tab" and linking to that instead?
That way you don't have to take a stand on a polarizing article but could get the benefit of the HN community's discussion?
HN usually has great discussion even on crummy topics and I can empathize with the intent to tap into such discussion on a subject of interest, but this dual posting (in my purely subjective opinion) has a whiff of deception about it - a "letter of the law" vs "spirit of the law" thing.
"by posting two articles, one pro-tab and one anti-tab, the submitter has neatly sidestepped that problem. "
Yes it is a neat hack. But I also agree with Mahmud in that this seems (somewhat) trollish.(What's next? Pairs of "Lisp is cool/ Lisp sucks" "Ruby is better than Python/Python is better than Ruby" articles? - Good on you for spotting it, Mahmud!)
i'm not suggesting that dual posts should become the norm, I'm just noting that this is a clever hack that illustrates a problem in the system. i think it's human nature to prefer a two-horse race where half the viewers root for one and the other half for the other, rather than a one-horse race where half the audience is rooting for, the other half against.
if this hack started becoming common, I'm sure the editors would eventually put a stop to it.
Nothing could be further from the truth. I was hoping for (and got) intelligent, measured discussion from a lot of smart people on the history, merits, demerits, etc of both approaches. I felt (and still believe) there would have been less discussion without both articles being posted. As it is, the HN front page often features opposing viewpoints simultaneously, one often in response to the other. Submitting them together simply accelerated the process. It's more interesting than a poll ("Spaces or Tabs?") and FAR more interesting than me typing up a summary of both arguments and submitting that instead, as you suggested in an earlier comment.
" I was hoping for (and got) intelligent, measured discussion"
the line between this and "argument" (used in the debating sense, not in the shout at each other sense) is very thin. The word to focus on is "provoke" not "argument". What makes it "argument" is that by setting up artificial poles opposed to each other simultaneously you are attempting a combative argument vs an exploratory one. That it didn't turn out that way is due to the strength of the HN community, which largely didn't take the bait. But bait in the water, there certainly was.
This is (imo) abuse of the system. Just do a thought experiment and imagine people submitting all kinds of paired posts (like you did) to get "intelligent measured responses" to their own questions - "Emacs is better than Vim"/ "Vim is better than Emacs", say. "Measured responses", sure!
HN would go to hell very fast if everone started looking for "measured responses" in this fashion. Quoting allenbrunson , "I'm just noting that this is a clever hack that illustrates a problem in the system.". It is clever. and it is abuse in that it takes advantage of a vulnerability in the system.
"I felt (and still believe) there would have been less discussion without both articles being posted."
yes this is the hack bit. And it works (as long as it is just the odd person doing this). Jumping a red light "works" too, if reducing the length of your trip is the only criterion.
"FAR more interesting than me typing up a summary of both arguments and submitting that instead, as you suggested in an earlier comment."
In other words you don't want to do any work up front but do want get people to argue each side of artificially paired posts. Hence the word "provoke".
As Allen said above, "if this hack started becoming common, I'm sure the editors would eventually put a stop to it."
In other words, it is only the rarity and novelty of this tactic that stops you from getting stomped on.
All that said, do what you will! If such abuse continues and spreads, the moderators will land on it with both feet.
Or you may indeed have found a superior method of topic submission and I am completely off base, in which case I'd expect the other participants on HN to copy your superior style of topic submission.
This is 2010. I'm using Visual Studio for most of my work and I never had to care about this tabs-vs-space thing. (When I work on Linux I use vim and I believe my macros are set up to use spaces but I'm not completely sure.) I don't even know which one Visual Studio is using and honestly, I don't really care either. It just works. It should be up to the IDE to sort out ridiculously marginal questions such as this.
Sometimes I want to copy/paste SQL from the source code to a command-line interface like mysql or sqlplus. Tab characters are interpreted as tab keypresses, triggering auto-completion. To get around it I have to open a blank file in a text editor, paste the SQL, convert the tabs to spaces, then highlight/copy it again. It's a pain in the ass. I can't be the only one with this problem, but I never see it mentioned in tabs/spaces debates.
Decent SQL editors (such as PL/SQL Developer for Oracle) have functionality to convert SQL to various formats such as single line or even multi-line strings for various languages.
You're being modded down as that's not a complete sentence, but yes, since there's a standard (PEP 8) stating that spaces are preferable to tabs, and that indentation should be 4 characters, and all modules I've seen use that standard, tabs are indeed looked upon as being bad in Python.
It's not just that. The REASON why tabs are so bad is because it makes very very subtle errors when they get mixed.
Additionally, tabs are 8 spaces to the python interpreter. If you're not using 8 space tab stop, you're setting up people who use your code for a world of hurt if they ever change anything in your files.
The REASON why tabs are so bad is because it makes very very subtle errors when they get mixed.
And the reason why spaces are bad is because it makes subtle errors when they get mixed in with tab-indented code. This is an argument for consistency, not for using spaces.
tabs and spaces are different things to the Python interpreter. If you really want to, you can mix them in your code. But you cannot mix tabs and spaces on the same indent level.
Tabs aren't just used at the beginning of lines. There might be a left-aligned, multi-line comment to the right of a block of code(...)
I cannot fathom what point he thinks he's making with these. If you're using tabs in a way that depends on tab width, you're doing it wrong.
Tab indentation generally means that one tab character is one layer of indenting. That's it. It's about semantic structure, not layout.
If you want to make ASCII art, or align things like paragraph-style comments, or "indent" things that aren't part of a block of code like pieces of a lengthy conditional clause split over multiple lines, use spaces instead (and then the five people who use proportional fonts will complain that using spaces for alignment "isn't portable"). Of course, if you're using a language with an off-side rule for syntactic whitespace even a die-hard tabber ought to just use spaces.
Personally, I dislike that sort of non-semantic formatting business in source code (and I think off-side rules in syntax are a horrible idea), but that's a matter of taste. And obviously, consistency is vastly more important than the particulars of indenting style. But I get tired of people arguing against tabs on the basis of not knowing how to use them properly.
On the other hand, this unintentionally makes a different, very strong argument in favor of using spaces: people can't manage to use tabs properly, so don't let them. This is why we can't have nice things, folks!