| |||||||||||||
Eight character tabsEight character tabsPosted Oct 30, 2012 21:49 UTC (Tue) by man_ls (subscriber, #15091)In reply to: Eight character tabs by nix Parent article: Thoughts on the ext4 panic 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.
(Log in to post comments)
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!)
|
|||||||||||||