+1 for the kernel coding style
I can understand (grudgingly) 4 spaces for Python
But for C/C++ 4 spaces are awful. Maybe because C lines end up being longer?
Tabs, they exist. Use them
I can understand (grudgingly) 4 spaces for Python
But for C/C++ 4 spaces are awful. Maybe because C lines end up being longer?
Tabs, they exist. Use them
Then the additional issue that everyone maps tabs to a different amount of space characters.
Only spaces can give a proper consistency without relying on external tools.
To me, the problem is consistency. I'm a 4 space man myself, but tabs don't outright offend me, as long as they're everywhere. I'd rather commit edits with tabs than attempt to convert the whole project to spaces, or worse, commit some spaces and some tabs to a single file/project.
This fully breaks the indentation, which is exacerbated when multiple teams working on the same code basis use different editors and tab settings.
So in the end one needs to rely on external tools that go over the source code to normalize the use of tabs.
A tab means 8 spaces. If you want your editor to show something different that's up to you, but it's non standard.
On the real corporation world, it is a whole different thing.
Good luck enforcing coding styles across multi-site projects, with rotating developers and off-shoring subcontractors.
Still, projects like this have something very thorough and that goes much deeper than just tabs vs spaces: http://www.stroustrup.com/JSF-AV-rules.pdf
If you have a source file with only tabs (and you should, then nobody has to run an re-indent script because they can't read it), you should be inserting tabs. If you have a source file with only spaces, you should map the tab key to insert the correct amount of spaces before editing. If you have a source file with both tabs and spaces for indentation, you should re-indent.
Type this in a bash terminal: $ printf '1234567890\n\tx\n'
For the second paragraph: I couldn't agree more. There's even some "geniuses" that indent python with the 1st level being 4 spaces and the second level as a tab. * sigh *. Really.
printf '1234567890\n1\tx\n12\tx\n123\tx\n1234\tx'
1234567890
1 x
12 x
123 x
1234 x
This is a non issue when you have nothing to the left of the code (that is, when indenting)
(and the x should be under the 9 btw)
Therefore, to me, your 'every language' reduces to a list of one.
https://docs.google.com/document/d/1HMxg6fv_yig_mVvnxsC8CwTf...
Unfortunately I haven't had time to update the code, and it doesn't work with more recent versions of emacs. Now I'm using vim and all-spaces-all-the-time.
However, after a character that's not a tab, i.e. any printable character, spaces should be used.
It is the best of both worlds, and can never be misconfigured by changing the number of spaces that a tab represents.
It is also what tab advocates have been saying for years now.
Then again, i haven't had the chance to define the coding style guide of anything bigger than a hobby project, so i might be lacking pragmatic experience.
Every editor can do it, I'm not complaining about pressing the space bar 4 times.
I'm complaining about the appearance of code indented with 4 spaces.
It's ludicrous that these space-wielding heretics (to borrow from the kernel style guide) are keeping everyone from having that.
In short: configure your editor to display to your tastes and save to whatever style guide you use in your organization. Problem solved.
You might also be surprised by how many source files with indentation spaces have off-by-one indentation errors.
I will add that to my list of arguments against using spaces for indentation. It is so true.
vim has 8 spaces for tabstop and that's what its docs say:
"Note: Setting 'tabstop' to any other value than 8 can make your file appear wrong in many places (e.g., when printing it)."