| |||||||||||||
Eight character tabsEight character tabsPosted Oct 30, 2012 13:01 UTC (Tue) by man_ls (subscriber, #15091)In reply to: Thoughts on the ext4 panic by nix Parent article: Thoughts on the ext4 panic The 80-char wrapping is obsolete, but the 8-char tab rule is just... puzzling. I usually have 4-char tabs and it works fine. I have used 2-char tabs and they work fine most of the time -- and that was for Python where indentation can get a bit hairy without {} blocks to guide the eye. The kernel coding style implies that 8-char tabs are easier to the eye, but that is a bit subjective -- for me they are much harder to read. Is there any real reason why you cannot display tabs as 4 characters locally in your Linux code? After all Linux does use the tab character. I realize that you risk being burnt alive at the stake in some Linux conference if you forget to change tab length and they spot you, but that is a small price to pay for being able to read code comfortably.
(Log in to post comments)
Eight character tabs Posted Oct 30, 2012 14:32 UTC (Tue) by nix (subscriber, #2304) [Link]
Changing the local tab width is safe as long as you never ever use spaces to indent anywhere, even on the ends of tabs to line up arguments in multi-line argument lists. That's... rare, and if people proceed to change tab widths and then line up arguments using *that* width, the result is just a mess for everyone. (Just another reason why it is basically a mistake to use tabs for anything. Spaces everywhere! I note that even GNU software, long a weird 8-char-tab-for-indentation-but-four-char-indent holdout, is slowly switching to spaces, project by project, because dealing with tabs has failure cases that just don't exist if you use spaces everywhere.)
Eight character tabs Posted Oct 30, 2012 14:41 UTC (Tue) by paulj (subscriber, #341) [Link]
Well, dealing with spaces has failure cases that just don't exist if you use tabs everywhere :). But yes, over all, too many people will get tabs wrong that standardising on spaces - inferior as they are - is the only option.
Eight character tabs Posted Oct 30, 2012 17:26 UTC (Tue) by nix (subscriber, #2304) [Link]
I don't see anything wrong with spaces. They make your uncompressed source code 10% or so larger, but these days that has no effect at all on anyone unless you're dealing with a source tree as large as, say, Chromium's. Everyone knows how big a space is, nobody can decide to make it take up more horizontal space... spaces are nice and uncontroversial and always work. Tabs don't.
Eight character tabs Posted Oct 30, 2012 21:49 UTC (Tue) by man_ls (subscriber, #15091) [Link] The problem with spaces is exactly that you cannot change indentation on the fly just by changing the local configuration. Every developer can choose the tabstop that suits them better. It is even possible to have different configurations for different situations: one for the laptop screen, another when the laptop is hooked to a monitor, etcetera. Spaces don't allow that.Also, it takes longer to press space four times (or eight) than tab once. You can usually configure your favorite editor to insert the spaces when tab is pressed, even to delete them (:set expandtab in vim), so this issue is not so important. As to the failure case you mention above, it makes sense to indent always using tabs, consistently. I have now remembered my painful days of aligning arguments using spaces -- it is just not worth it. I prefer to use short argument lists and set line wrap at 120 so I don't ever see multi-line argument lists; if they arise then just indent into a new line.
Eight character tabs Posted Oct 31, 2012 0:42 UTC (Wed) by nix (subscriber, #2304) [Link]
Unfortunately changing indentation on the fly by changing tabs never, ever works. It only works if all developers are utterly rigorous about only ever indenting with tabs, always indenting with strictly one more tab, never using tabs to line anything up -- and, oh yes, never trying to make anything line up at all. If you like a coding style which lines up wrapped parameters one column after the open bracket of the call on the previous line (a very common style) you cannot do it, even with tabs, and expect indentation-changing-via-tab to work.
I have never worked on a codebase where changing indentation via tab width changes did anything but turn the codebase into goo. It is hopeless.
The way to reindent is via automatic reindentation programs (such as GNU indent). Teach that your indentation style, and you're home free. Nothing else works.
Eight character tabs Posted Oct 31, 2012 1:05 UTC (Wed) by bronson (subscriber, #4806) [Link]
... and then somehow unreindent before you commit your code? Otherwise, unless you enforce company-wide indent settings (good luck!), most of your changes will be whitespace churn.
I'm at the point where I'm ready to declare that, on a real world codebase with multiple teammembers, nothing at all works. Nobody likes the whitespace gestapo.
Eight character tabs Posted Oct 31, 2012 8:52 UTC (Wed) by man_ls (subscriber, #15091) [Link] You can try telling git to ignore whitespace.My point of view is a bit different: tabs are good, therefore avoid everything that doesn't work with tabs. Lining things up is evil, hard wrap-up limits are evil, and so on. Yes, it requires a lot of discipline, but then so does software development in general.
Eight character tabs Posted Oct 31, 2012 13:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Yeah, automated reindentation before commit only works if you have something pre-commit that reindents again. I've worked on projects with such rules, and it does work (certainly better than what we had before, with people with all sorts of tab widths and odious 'optimizing' editors that translated spaces to tabs of whatever width the user had set throughout the entire file on every save). Better yet is to adapt to whatever the coding standard of the project is and just eat your whining most of the time. (Says the guy who whined about part of the kernel's coding standards just a few posts up. Hypocrisy is *good* for you!)
Eight character tabs Posted Oct 31, 2012 11:40 UTC (Wed) by etienne (subscriber, #25256) [Link]
> spaces are nice and uncontroversial and always work. Tabs don't.
Well, have you ever used an editor with variable width font?
Also, in some case (long debug printf() line), breaking the long line makes the structure of the function more complex than it really is; just tell you editor not to wrap and just ignore the end of the printf() line - it is just a printf()!
Eight character tabs Posted Oct 31, 2012 13:21 UTC (Wed) by nix (subscriber, #2304) [Link]
Variable-width fonts don't work at all for most programming languages for the reasons you state. I actually tried to use a variable-width font only for comments for a while, but it really messes up ASCII-art, and the places where you find ASCII-art in comments are generally the places where the code is complex enough to *need* it, and you don't want to have difficulty piled on by interpreting proportional-font damage too.
Eight character tabs Posted Oct 31, 2012 17:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
printf() - a function famous for never having been implicated in any complicated security bugs. Oh wait.
No, thanks all the same but I'd rather actually see the code I'm maintaining and not trust that the bits I can't see aren't important.
I like the ASCII control characters, but most of them don't belong in my source code and that includes U+0009 TAB. Use soft tabs, set the continuous integration software to barf on hard tabs in source code, along with mysterious trailing whitespace and similar sins.
Eight character tabs Posted Oct 31, 2012 18:52 UTC (Wed) by nix (subscriber, #2304) [Link]
I don't understand your debug printf() comment at all. You can always break a printf() line, even in the format string, with string literal concatenation.
Eight character tabs Posted Nov 1, 2012 9:41 UTC (Thu) by ncm (subscriber, #165) [Link]
Me, I've never understood why people insist that printf format strings should be indented at all. I push them to the left margin, and it brings no confusion, but much clarity.
Eight character tabs Posted Nov 1, 2012 12:06 UTC (Thu) by etienne (subscriber, #25256) [Link]
But most of the time you want to understand the structure of the function you are about to modify, even if you have (probably commented) printf's showing that you entered the function with those parameters, that you are calling that other function with those parameters, what is the value of each of the fields of that structure...
Having 3/4 lines of code with no algorithm meaning does not help to see the structure of the code and is difficult to comment/uncomment at once; it is easier to tell your editor not to wrap lines and so not display the end of those (probably commented) lines. Obviously you can write the functions print_mystruct_and_cpt(), print_mystruct_and_idx(), ... that you call only once in a commented out block. Linux source do not have much "logging" lines, so it is not a real problem there.
Eight character tabs Posted Oct 30, 2012 18:11 UTC (Tue) by marcH (subscriber, #57642) [Link]
> But yes, over all, too many people will get tabs wrong that standardising on spaces - inferior as they are - is the only option.
Tab indentation was invented to illustrate "The perfect is the enemy of the good".
Let everyone have his own indentation taste from the same source? Great idea on paper. Falls apart on a regular basis. Because it's not compatible with lining up across lines, because it's not compatible with a max width, etc. And because people are only human and will not be disciplined enough.
Eight character tabs Posted Oct 31, 2012 11:37 UTC (Wed) by Jonno (subscriber, #49613) [Link]
Lining up arguments in tab-indented code works just fine, iff you use the same number of tabs for indentation, and then line up the arguments with spaces.
Eight character tabs Posted Oct 31, 2012 18:09 UTC (Wed) by marcH (subscriber, #57642) [Link]
"In theory, theory and practice are the same. In practice, they are not."
|
|||||||||||||