What's the deal with tab size (8 spaces) in the GitHub UI?(github.community)
github.community
What's the deal with tab size (8 spaces) in the GitHub UI?
https://github.community/t/whats-the-deal-with-tab-sizes-on-github-gists/954
81 comments
That's certainly true for spaghetti kernel or firmware code, but certainly not true for application code, with a much higher abstraction.
8 char indentation also doesn't make your code easier to read, on the contrary. Your eyes need to move much further.
8 char indentation also doesn't make your code easier to read, on the contrary. Your eyes need to move much further.
That's all well and good for Linux-style C programming maybe, but it would be painful in languages like C#.
EG the simplest function in a Unity game, that prints "hello world" for the player only would be something like:
EG the simplest function in a Unity game, that prints "hello world" for the player only would be something like:
namespace Something
{
class SomeClass
{
void Awake()
{
if (CompareTag("Player"))
{
print("Hello, world")
print("This line's closing bracket is at # 80")
}
}
}
}The new C# 6 templates don't require namespace or class blocks - for this reason I suppose.
Pretty much every language with a class that contains a function with a loop that breaks on an inner condition would be 4 levels deep.
I suppose Objective-C would only be 3 deep, but I can't think of any others off the top of head.
I do like having the namespace there, if only to gently nudge you towards better architecture.
As a temp fix I have overridden Rider's code formatting to not indent within the namespace, but C# 10 will bring file scoped namespaces. You can just declare the namespace between the imports and the classes, and everything in the file will be namespaced automatically.
As a temp fix I have overridden Rider's code formatting to not indent within the namespace, but C# 10 will bring file scoped namespaces. You can just declare the namespace between the imports and the classes, and everything in the file will be namespaced automatically.
I've heard this "no more than 3 levels of indentation" thing before, but isn't that somewhat language specific? If in coding in python, I have 1 level for being inside a class, 1 level for being inside a function, and that gives me only 1 level to write actual program flow with. I find it hard to believe that a double nested for loop, having 4 levels of indentation, is in-itself a sign that I have to "fix my program".
List comprehensions in Python allow you to avoid having to add another level of indentation. If the feature did not exist, a lot of Python code would be one more level deep. Language features definitely have an effect on the number of indentation levels you need. Map and reduce reduce the number, Node-style callbacks increase it, etc.
Although I suppose a Linux kernel developer would consider having to write Node JS code as 'being screwed'.
Although I suppose a Linux kernel developer would consider having to write Node JS code as 'being screwed'.
Personally I agree with the sentiment of no more than three indentations, but I don't take it as a hard rule (mostly because I'm not writing kernel code).
I think it is very language specific. In Python I'd probably ignore the "rule" outright.
I think it is very language specific. In Python I'd probably ignore the "rule" outright.
The 3 levels of indentation, is about being mindful of runtime complexity. For example, do you really need four or more levels of for loops in a function.
This "rule" is very domain specific.
If you are writing for the Linux Kernel. You should rethink your strategy if you need something that is very nested.
However there are places that where such nesting might be the favorable way to do a task so that the code maintains long term readability. Most often this is for something that runtime complexity isn't a important factor. I've seen this most often in document and report generation.
This "rule" is very domain specific.
If you are writing for the Linux Kernel. You should rethink your strategy if you need something that is very nested.
However there are places that where such nesting might be the favorable way to do a task so that the code maintains long term readability. Most often this is for something that runtime complexity isn't a important factor. I've seen this most often in document and report generation.
I have a hard time believing these opinions are correct because they were heavily constrained based on column size and monitors of the old days.
So it’s not like the community freely came to this conclusion after a lot of informed experimentation.
So it’s not like the community freely came to this conclusion after a lot of informed experimentation.
Just because you have an ultra-wide, 8K monitor in 2021 doesn't mean it's a good idea to write 400 character lines. This argument is specious.
In fact 80 columns is as much related to readability as it is to hardware limitations of yore.
100-something columns for code can be a pretty big relaxation over 80, but beyond that it gets into diminishing returns.
In fact 80 columns is as much related to readability as it is to hardware limitations of yore.
100-something columns for code can be a pretty big relaxation over 80, but beyond that it gets into diminishing returns.
I generally agree. I once played with 130 and found that to be crazy. Settled on 100 (when it's my own project).
My point is that it's not like they came up with these opinions based on a sandbox of experimentation. The opinions on line length, indentation, etc. are all results of constraints at the time. Which makes the opinions on things like "80 chars, 8 char tabs" feel like retcons.
My point is that it's not like they came up with these opinions based on a sandbox of experimentation. The opinions on line length, indentation, etc. are all results of constraints at the time. Which makes the opinions on things like "80 chars, 8 char tabs" feel like retcons.
[deleted]
This presumes one isn't using real tab characters in their code. (No idea why they claim tabs are 8 spaces, as they're their own character.) The rest of these arguments are just curious decisions by a certain community. The point is for the visual indentation to be up to the end user, seasoned to taste. Requiring some code viewer to stick to n spaces is unfriendly. (I'd sooner quit programming altogether than follow the above rules.)
4 character indents are already too big. 8 character indented code is vomit inducing. 2 character indents and any modern monospace font is enough for readability.
I concede that reading 2 indented is hard when you begin braces on a new line - but then your problem is beginning braces on a new line, not the indent.
I concede that reading 2 indented is hard when you begin braces on a new line - but then your problem is beginning braces on a new line, not the indent.
I'm one of the monsters that prefers 2 space tabs for my small monitor, 2 files side by side.
Like you said and other comments, no newline opening braces, don't mix tab and space for OCD trailing comment and argument alignment.
On the other hand, I don't code for 20 hours straight because I need to do laundry and dishes and family stuff.
Like you said and other comments, no newline opening braces, don't mix tab and space for OCD trailing comment and argument alignment.
On the other hand, I don't code for 20 hours straight because I need to do laundry and dishes and family stuff.
At least most people are agreeing on using tabs, as opposed to putting spaces in and trying to hardcode their preference.
If we use tabs, then we can just have whatever tab stop we personally want, and nobody else is the wiser.
If we use tabs, then we can just have whatever tab stop we personally want, and nobody else is the wiser.
Huh? I have never worked anywhere that used tabs.
Huh? I have never worked anywhere that uses spaces.
Truly scary honestly. I cringe whenever I see spaces hardcoded. I feel the same way about line width with hard stops too though. There is no longer a need for line limits and is the whole point of linewraps.
i've never understood why spaces are used for indentation, bit i've ended up adopting it because if everyone else is using spaces, i can't very well use tabs.
there's, like, a message in there about life and society.
there's, like, a message in there about life and society.
Because everyone has tabs set differently, so code always looks wrong, even if you use the same editor. A space is a space is a space.
> always looks wrong
Only if you are mixing tabs and spaces in a strange way. If you use tabs reasonably then it looks right to each user's preferences.
I think the reason that spaces are popular are that it is more obvious when done wrong. We should probably just have better code review tools that highlight when tabs are used for anything but initial indentation. It is as simple as /[^\t]\t/.
The other downside of tabs is that you don't have a well defined line width, but IMHO line limits are a fairly silly lint anyways, you should make the code look reasonable. I find that formatters based on line length limits tend to make code very awkward to read.
Only if you are mixing tabs and spaces in a strange way. If you use tabs reasonably then it looks right to each user's preferences.
I think the reason that spaces are popular are that it is more obvious when done wrong. We should probably just have better code review tools that highlight when tabs are used for anything but initial indentation. It is as simple as /[^\t]\t/.
The other downside of tabs is that you don't have a well defined line width, but IMHO line limits are a fairly silly lint anyways, you should make the code look reasonable. I find that formatters based on line length limits tend to make code very awkward to read.
I think it’s as simple as the fact that spaces are easy to hit with your thumb, and tabs are hard to hit with your pinky. At least that’s why I do it!
I think the role of a tab in a code editor is different from the role of a tab in a document editor. I have always used dedicated code editors and prefer tabs (but like you, I use and specify spaces for code style). I think people who use editors that are multi-purpose generally see these alternate usages of tab as problematic or even illogical. I think this is often the linux people, and they are often the most experienced and influential coders. I think that is why spaces are generally seen as the preferred method.
Which fails silently - someone will make a change that looks good to them, but messes up indentation for anyone else with a different tabstop. Indeed two people looking at the same code might disagree about which block some statements were part of.
If you want to use tabs for indentation then you absolutely must enforce that they are used consistently, and I've never seen any organisation succeed at that. Whereas if you use spaces then you can simply ban the tab character from all source files (which organisations do enforce), and then at least you guarantee that everyone will see the same thing when they look at a given piece of code.
If you want to use tabs for indentation then you absolutely must enforce that they are used consistently, and I've never seen any organisation succeed at that. Whereas if you use spaces then you can simply ban the tab character from all source files (which organisations do enforce), and then at least you guarantee that everyone will see the same thing when they look at a given piece of code.
What you're describing isn't messed up indentation but messed up column alignment (trying to align content on multiple lines).
Indent only using tabs, based only on scoped, and there's no possibility of problems. It's super simple to enforce via linting.
People who love column alignment are really painting their code on a grid of characters and expect to be able to paint any coordinate. There are even editors that let you click past the end of the line and they'll fill in all the spaces to that point. It's madness, I tells ya.
Indent only using tabs, based only on scoped, and there's no possibility of problems. It's super simple to enforce via linting.
People who love column alignment are really painting their code on a grid of characters and expect to be able to paint any coordinate. There are even editors that let you click past the end of the line and they'll fill in all the spaces to that point. It's madness, I tells ya.
> What you're describing isn't messed up indentation but messed up column alignment (trying to align content on multiple lines).
It's still indentation - the point is lining up the start of a line with some point on the line above.
> It's super simple to enforce via linting.
And yet I've never seen anywhere manage to actually enforce it in practice.
It's still indentation - the point is lining up the start of a line with some point on the line above.
> It's super simple to enforce via linting.
And yet I've never seen anywhere manage to actually enforce it in practice.
Relevant Silicon Valley scene: https://www.youtube.com/watch?v=SsoOG6ZeyUI
I hate that scene. "I run a compression company" but apparently he doesn't know that spaces are trivially compressible and that both HFS+ and APFS have built-in file compression?
No you can't, because material that is aligned between lines that have different indentation gets screwed.
This is a nonstarter. If you use tabs, assume 8, or don't use tabs.
If you want flexible tabs, you must rigidly adhere to formatting rules which ban internal alignment between lines that are at different indentation levels.
Problem with this banning is that whereas it reasonably applies to comments like what I showed, those comments are a strawman example of internal alignment. Here is a less of a strawman example:
If you want code that looks good with different tab sizes, that's a goal. Goals have to be verified and enforced, or they fall apart. You need a well-written commit filter which detects situations where moving tabs will wreck apparent alignment, or else team members need to waste their time policing this in reviews.
The most productive thing is to just ban tabs. The code looks one way, modulo your local font setting, and that's it.
struct foo { /* nicely aligned
int x; * comment or whatever
int y; * designed for two-space tab */
};
struct foo { /* nicely aligned
int x; * comment or whatever
int y; * designed for two space tab */
};
This is a nonstarter. If you use tabs, assume 8, or don't use tabs.
If you want flexible tabs, you must rigidly adhere to formatting rules which ban internal alignment between lines that are at different indentation levels.
Problem with this banning is that whereas it reasonably applies to comments like what I showed, those comments are a strawman example of internal alignment. Here is a less of a strawman example:
{
function(arg, arg,
arg, arg);
}
{
[Tab]function(arg, arg,
[Tab] arg, arg);
}
If you want code that looks good with different tab sizes, that's a goal. Goals have to be verified and enforced, or they fall apart. You need a well-written commit filter which detects situations where moving tabs will wreck apparent alignment, or else team members need to waste their time policing this in reviews.
The most productive thing is to just ban tabs. The code looks one way, modulo your local font setting, and that's it.
An alternative is to use soft tabs for anything that needs to be aligned, especially if the things appears after other code which is already indented. An even better alternative is to not use align code like this, as it invariably leads to soul crushing diffs and merge conflicts when you have to change the size of the longest line.
Just tab in under the function definition on a new line. Done.
>The most productive thing is to just ban tabs.
There are valid accessibility reasons to prefer tabs to spaces.
>The most productive thing is to just ban tabs.
There are valid accessibility reasons to prefer tabs to spaces.
There simply aren't. The accessibility problem has to be solved such that people with visual impairments can just as effectively work with code that is indented with spaces, because there is a lot of it out there and you cannot just reindent everything with tabs.
Just because code is indented with character 32 rather than 9 doesn't mean that this indentation cannot be presented in an adjustable way.
Just because code is indented with character 32 rather than 9 doesn't mean that this indentation cannot be presented in an adjustable way.
Notepad++ has a nice feature to convert leading spaces and tabs back and forth though I never used it on a big mess of a file to convert to tabs to see if it is successful there.
Every editor I've encountered beyond Notepad/Wordpad let's the user specify tabwidth.
The accessiblity issue for me is poverty and eyestrain. I like big fonts on my small monitor in my small apartment.
I'm curious, why would you ever want to align something like that? I've only ever seen "but it breaks my alignment" as the only argument from the spaces people but so far I have not yet seen a good reason as to why that alignment is desired in the first place. Comments like that seem extremely unlikely to me, comments are for explaining a non-obvious "but why" and that's better in a paragraph above the code, especially if you use tools like doxygen who expect them there.
And in the function example I assume you do it because the args don't 'fit' on one line but then why not just have your editor wrap the line (and optionally indent by one level)? To spot the function name better? Why not use syntax highlighting for that?
And even then just use tabs for indentation and spaces for alignment, what would be the reason to force spaces on everyone else and make them suffer from an indentation width they don't like?
And in the function example I assume you do it because the args don't 'fit' on one line but then why not just have your editor wrap the line (and optionally indent by one level)? To spot the function name better? Why not use syntax highlighting for that?
And even then just use tabs for indentation and spaces for alignment, what would be the reason to force spaces on everyone else and make them suffer from an indentation width they don't like?
> I have not yet seen a good reason as to why that alignment is desired in the first place
Alignment is desired because it enhances readability. All good visual design incorporates elements of alignment, grouping, separation and so on.
> why not just have your editor wrap the line
We could write function calls, no matter how many arguments they have or how large the expressions, on one line. That will result in an excessive line length. Generally, you want to avoid code wider than about 100 columns.
You may find yourself working with a prescribed coding convention which imposes such a constraint.
If you rely on an editor wrapping the line in a clever way, that's good for you. But you don't now how other tools will react to the long lines. E.g. someone wanting a print out of the code may find that the lines are getting truncated.
> what would be the reason to force spaces on everyone else and make them suffer from an indentation width they don't like?
Using tabs for indentation and spaces for alignment requires extra care, and a carefully tuned editor setup which understands the semantic difference between the tabs and the spaces which follow. In any sizeable team, deviations in formatting will creep in. Enforcing it will just be a big waste of time, compared to the simplicity of banishing tabs.
People who suffer from an indentation width they don't like have a psychological problem that perhaps makes them unsuitable for this line of work. The professional developer can happily work with any indentation format and maintain it as-is.
The only halfway valid argument here is regarding people with severe visual disabilities. Everything else is whiny primadonna fluff.
Tabs are still not the right tool here; accessibility has to be solved in such a way that the visually disabled developer is able to work equally well with any code that is thrown their way, tabs or spaces. You don't get to work on nothing but code that was developed in-house with accessibility in mind. Third-party code happens.
Also, you are overlooking that indentation isn't necessarily aligned to an absolute grid of tab stops. Nested indentation can start at a misaligned position.
It could work if tabs actually expanded to a fixed number of spaces, rather than advancing to an aligned tab stop.
Alignment is desired because it enhances readability. All good visual design incorporates elements of alignment, grouping, separation and so on.
> why not just have your editor wrap the line
We could write function calls, no matter how many arguments they have or how large the expressions, on one line. That will result in an excessive line length. Generally, you want to avoid code wider than about 100 columns.
You may find yourself working with a prescribed coding convention which imposes such a constraint.
If you rely on an editor wrapping the line in a clever way, that's good for you. But you don't now how other tools will react to the long lines. E.g. someone wanting a print out of the code may find that the lines are getting truncated.
> what would be the reason to force spaces on everyone else and make them suffer from an indentation width they don't like?
Using tabs for indentation and spaces for alignment requires extra care, and a carefully tuned editor setup which understands the semantic difference between the tabs and the spaces which follow. In any sizeable team, deviations in formatting will creep in. Enforcing it will just be a big waste of time, compared to the simplicity of banishing tabs.
People who suffer from an indentation width they don't like have a psychological problem that perhaps makes them unsuitable for this line of work. The professional developer can happily work with any indentation format and maintain it as-is.
The only halfway valid argument here is regarding people with severe visual disabilities. Everything else is whiny primadonna fluff.
Tabs are still not the right tool here; accessibility has to be solved in such a way that the visually disabled developer is able to work equally well with any code that is thrown their way, tabs or spaces. You don't get to work on nothing but code that was developed in-house with accessibility in mind. Third-party code happens.
Also, you are overlooking that indentation isn't necessarily aligned to an absolute grid of tab stops. Nested indentation can start at a misaligned position.
(let ((fun (lambda (arg)
(indented-two-spaces))))
(also-two-spaces))
(let ((func (lambda (arg)
(indented-two-spaces))))
(also-two-spaces))
It could work if tabs actually expanded to a fixed number of spaces, rather than advancing to an aligned tab stop.
(let ((fun (lambda (arg)
[TAB](indented-by-simply-expanding-tab))))
[TAB](also-indented-by-tab with
[TAB] split arguments))
[TAB](let ((fun (lambda (arg)
[TAB] [TAB](indented-by-naive-tab))))
[TAB][TAB](also-indented-by-tab with
[TAB][TAB] split arguments))
> Alignment is desired because it enhances readability.
While that's true I was asking specifically about those examples of yours. What would be the reason to have a weird L shaped comment around the code like that? Right now I can only see two situations in which something is aligned in code, the first one being something like this
The second one are function arguments over multiple lines. Personally again I find it a bit ridiculous that someone absolutely needs to have
> Enforcing it will just be a big waste of time, compared to the simplicity of banishing tabs.
I don't think a clang format commit hook is that hard to enforce. Not to mention that you are enforcing formatting anyway, otherwise you end up with one person using 2 spaces and the other 8. And if you already enforce that then there is no reason to not just enforce using tabs for indentation since they are objectively superior.
> People who suffer from an indentation width they don't like have a psychological problem that perhaps makes them unsuitable for this line of work. The professional developer can happily work with any indentation format and maintain it as-is.
> The only halfway valid argument here is regarding people with severe visual disabilities. Everything else is whiny primadonna fluff.
Do you really think that dismissing people's preferences as psychological disorders is a good idea? Especially in a community that likes to customize the shit out of everything? Why shouldn't they be allowed to see the code however they like? That's literally the idea of using tabs, you can see them as 37 spaces if you like but for me it's 4. If you want to do any extra alignment after the indentation then use spaces, sure. But who are you to decide how far right on my screen the body of the loop appears? Tbh if you ask me I find your proposal straightup draconic, you rather ban tabs completely rather than using the available tooling and/or properly training your people to enable everyone to work as they see fit. Yeah sure most people can work with a 8 spaces codebase if forced to but that doesn't mean it's a good idea.
And since you brought up disabilities: I've worked with someone who had only one eye, he didn't do any indentation because otherwise he'd have to constantly move his head around. Set tabwidth to 0 in his editor and you don't need to do any reformatting on commits if you indent using tabs. Force spaces on everyone and he needs to do a reformat all the time.
> (I don't think my editor can do this and don't know of any which can).
I'm not sure I follow why this is necessary. They already act like that, the only tabs not being as wide as X spaces are the ones that follow a non-tab character and at that point you are no longer doing indentation anyway so a tab should not even exist there. Though I don't see a reason to not have this, should be a simple setting in any editor.
While that's true I was asking specifically about those examples of yours. What would be the reason to have a weird L shaped comment around the code like that? Right now I can only see two situations in which something is aligned in code, the first one being something like this
int foo;
double a;
The second one are function arguments over multiple lines. Personally again I find it a bit ridiculous that someone absolutely needs to have
void foo(arg, arg
arg, arg)
{
...
}
void foo(
arg, arg,
arg, arg)
{
...
}
> Enforcing it will just be a big waste of time, compared to the simplicity of banishing tabs.
I don't think a clang format commit hook is that hard to enforce. Not to mention that you are enforcing formatting anyway, otherwise you end up with one person using 2 spaces and the other 8. And if you already enforce that then there is no reason to not just enforce using tabs for indentation since they are objectively superior.
> People who suffer from an indentation width they don't like have a psychological problem that perhaps makes them unsuitable for this line of work. The professional developer can happily work with any indentation format and maintain it as-is.
> The only halfway valid argument here is regarding people with severe visual disabilities. Everything else is whiny primadonna fluff.
Do you really think that dismissing people's preferences as psychological disorders is a good idea? Especially in a community that likes to customize the shit out of everything? Why shouldn't they be allowed to see the code however they like? That's literally the idea of using tabs, you can see them as 37 spaces if you like but for me it's 4. If you want to do any extra alignment after the indentation then use spaces, sure. But who are you to decide how far right on my screen the body of the loop appears? Tbh if you ask me I find your proposal straightup draconic, you rather ban tabs completely rather than using the available tooling and/or properly training your people to enable everyone to work as they see fit. Yeah sure most people can work with a 8 spaces codebase if forced to but that doesn't mean it's a good idea.
And since you brought up disabilities: I've worked with someone who had only one eye, he didn't do any indentation because otherwise he'd have to constantly move his head around. Set tabwidth to 0 in his editor and you don't need to do any reformatting on commits if you indent using tabs. Force spaces on everyone and he needs to do a reformat all the time.
> (I don't think my editor can do this and don't know of any which can).
I'm not sure I follow why this is necessary. They already act like that, the only tabs not being as wide as X spaces are the ones that follow a non-tab character and at that point you are no longer doing indentation anyway so a tab should not even exist there. Though I don't see a reason to not have this, should be a simple setting in any editor.
> there is no reason to not just enforce using tabs for indentation since they are objectively superior.
I just demonstrated one. The semantics of tabs is that they move the printing position to the next tab stop position, which is absolutely determined, rather than relatively.
This does not work for nested indentation in modern (or even not-so-modern) programming languages.
If we re-imagine the tab as simply being a macro which expands to a configurable number of spaces, then tabs could be objectively superior.
It makes sense to advocate for that, and I'm all for it; but I don't place a high probability on it happening. Though a simple idea, it would have to be in every editor, and other tools.
You almost want to re-purpose some other control character for this purpose and leave tab alone.
About:
Ideally, this principle would be applied to every syntactic element.
Looking at complex examples of Lisp code, I can't find a single counter-example: every sub-expression can be boxed in a rectangle which includes only that expression and its constituents: modulo a few closing parens that are written out to the right: )))). A big example of this is given below.
Now in the descendants of C syntax, the predominant brace placements throw a monkey wrench into this idea. We usually cannot draw a bounding box around a multi-line compound statement or other braced element such that the braces are included, and no tokens of neighboring constructs are included.
About that other style, for consistency, I would want this:
I work in a shop where the style closely resembles this one, except the parameter declarations are on separate lines:
I still wouldn't do this in a side project where I dictate the coding convention, but I can respect that and work with it without grumbling.
Now about that bounding box thing, here is a random example I picked from the SBCL compiler sources. The file is:
https://github.com/sbcl/sbcl/blob/master/src/compiler/srctra...
The macro bound-binop, with some ASCII rectangles inserted, looks like this.
Only the closing parentheses at the end violate the principle: the rectangle includes more parentheses than are strictly part of that syntax, and this problem is minimized by closing the parentheses together on the same line.
I suspect that the programmers who work with Lisp and find it readable all grok this bounding box model, whether consciouosly or not.
I just demonstrated one. The semantics of tabs is that they move the printing position to the next tab stop position, which is absolutely determined, rather than relatively.
This does not work for nested indentation in modern (or even not-so-modern) programming languages.
If we re-imagine the tab as simply being a macro which expands to a configurable number of spaces, then tabs could be objectively superior.
It makes sense to advocate for that, and I'm all for it; but I don't place a high probability on it happening. Though a simple idea, it would have to be in every editor, and other tools.
You almost want to re-purpose some other control character for this purpose and leave tab alone.
About:
void foo(arg, arg
arg, arg)
{
...
}
void foo(arg, arg[Enter]arg, arg)[Enter]{[Enter]...[Enter]}
+----------+
void foo|(arg, arg |
| arg, arg)|
+-----------+
{
...
}
Ideally, this principle would be applied to every syntactic element.
Looking at complex examples of Lisp code, I can't find a single counter-example: every sub-expression can be boxed in a rectangle which includes only that expression and its constituents: modulo a few closing parens that are written out to the right: )))). A big example of this is given below.
Now in the descendants of C syntax, the predominant brace placements throw a monkey wrench into this idea. We usually cannot draw a bounding box around a multi-line compound statement or other braced element such that the braces are included, and no tokens of neighboring constructs are included.
About that other style, for consistency, I would want this:
void foo(
arg, arg,
arg, arg
)
{
...
}
I work in a shop where the style closely resembles this one, except the parameter declarations are on separate lines:
int put_bytes(
int fd, // comment
char *buffer, // comment
size_t size, // comment
)
{
}
I still wouldn't do this in a side project where I dictate the coding convention, but I can respect that and work with it without grumbling.
Now about that bounding box thing, here is a random example I picked from the SBCL compiler sources. The file is:
https://github.com/sbcl/sbcl/blob/master/src/compiler/srctra...
The macro bound-binop, with some ASCII rectangles inserted, looks like this.
Only the closing parentheses at the end violate the principle: the rectangle includes more parentheses than are strictly part of that syntax, and this problem is minimized by closing the parentheses together on the same line.
I suspect that the programmers who work with Lisp and find it readable all grok this bounding box model, whether consciouosly or not.
(defmacro bound-binop (op x y)
+-----------------------------------------------------------------------------------------------+
| (with-unique-names (xb yb res) |
| +-------------------------------------------------------------------------------------------+ |
| | `(and ,x ,y | |
| | +-----------------------------------------------------------------------------------+ | |
| | | (with-float-traps-masked (:underflow :overflow :inexact :divide-by-zero) | | |
| | | +-------------------------------------------------------------------------------+ | | |
| | | | +-------------------------------------+ | | | |
| | | | (let* |((,xb (type-bound-number ,x)) | | | | |
| | | | | (,yb (type-bound-number ,y)) | | | | |
| | | | | (,res (safely-binop ,op ,xb ,yb))) | | | | |
| | | | +-------------------------------------+ | | | |
| | | | +---------------------------------------------------------------------------+ | | | |
| | | | | (set-bound ,res | | | | |
| | | | | +--------------------------------------------------------------+ | | | | |
| | | | | | +----------------------------+ | | | | | |
| | | | | | (and |(or (consp ,x) (consp ,y)) | | | | | | |
| | | | | | +----------------------------+ | | | | | |
| | | | | | ;; Open bounds can very easily be messed up | | | | | |
| | | | | | ;; by FP rounding, so take care here. | | | | | |
| | | | | | +-----------------------------------------------------+ | | | | | |
| | | | | | |,(ecase op | | | | | | |
| | | | | | | +-------------------------------------------------+ | | | | | | |
| | | | | | | | (sb-xc:* | | | | | | | |
| | | | | | | | ;; Multiplying a greater-than-zero with | | | | | | | |
| | | | | | | | ;; less than one can round to zero. | | | | | | | |
| | | | | | | | `(or (not (fp-zero-p ,res)) | | | | | | | |
| | | | | | | | (cond ((and (consp ,x) (fp-zero-p ,xb)) | | | | | | | |
| | | | | | | | (>= (abs ,yb) 1)) | | | | | | | |
| | | | | | | | ((and (consp ,y) (fp-zero-p ,yb)) | | | | | | | |
| | | | | | | | (>= (abs ,xb) 1))))) | | | | | | | |
| | | | | | | +-------------------------------------------------+ | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | +-------------------------------------------------+ | | | | | | |
| | | | | | | | (sb-xc:/ | | | | | | | |
| | | | | | | | ;; Dividing a greater-than-zero with | | | | | | | |
| | | | | | | | ;; greater than one can round to zero. | | | | | | | |
| | | | | | | | `(or (not (fp-zero-p ,res)) | | | | | | | |
| | | | | | | | (cond ((and (consp ,x) (fp-zero-p ,xb)) | | | | | | | |
| | | | | | | | (<= (abs ,yb) 1)) | | | | | | | |
| | | | | | | | ((and (consp ,y) (fp-zero-p ,yb)) | | | | | | | |
| | | | | | | | (<= (abs ,xb) 1))))) | | | | | | | |
| | | | | | | +-------------------------------------------------+ | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | +-------------------------------------------------+ | | | | | | |
| | | | | | | | ((sb-xc:+ sb-xc:-) | | | | | | | |
| | | | | | | | ;; Adding or subtracting greater-than-zero | | | | | | | |
| | | | | | | | ;; can end up with identity. | | | | | | | |
| | | | | | | | `(and (not (fp-zero-p ,xb)) | | | | | | | |
| | | | | | | | (not (fp-zero-p ,yb)))))))))))) | | | | | | | |
| | | | | | | +-------------------------------------------------+ | | | | | | |
| | | | | | +-----------------------------------------------------+ | | | | | |
| | | | | +--------------------------------------------------------------+ | | | | |
| | | | +---------------------------------------------------------------------------+ | | | |
| | | +-------------------------------------------------------------------------------+ | | |
| | +-----------------------------------------------------------------------------------+ | |
| +-------------------------------------------------------------------------------------------+ |
+-----------------------------------------------------------------------------------------------+Okay I think I understand your core issue. My position is that you do one indent per open scope and those should be done by tabs. Since those usually appear at the beginning of the line there's no problem because tabs behave exactly like you want them to (equal X spaces). It also produces nice boxes, especially in C like languages if I may say so, personally I think Python forcing you to obey this principle is actually a good think to teach people. Can look like this:
+--------------------------------------+
|namespace foo |
|{ |
| +------------------------------+ |
|[TAB]|void bar(args) | |
|[TAB]|{ | |
| | +-----------------+ | |
|[TAB]|[TAB]|while (condition)| | |
|[TAB]|[TAB]|{ | | |
|[TAB]|[TAB]|[TAB]// body | | |
|[TAB]|[TAB]|} | | |
| | +-----------------+ | |
| | | |
| | // and another scope | |
| | +-----------------+ | |
|[TAB]|[TAB]|if (condition) | | |
|[TAB]|[TAB]|{ | | |
|[TAB]|[TAB]|[TAB]// body | | |
|[TAB]|[TAB]|} | | |
| | +-----------------+ | |
|[TAB]|} | |
| +------------------------------+ |
|} |
+--------------------------------------+
+--------------------------------------+
|namespace foo |
|{ |
| +------------------------------+ |
|[TAB]|auto bar(args) | |
| | // function body | |
|[TAB]|{ | |
|[TAB]|[TAB]return baz([args](){ | |
|[TAB]|[TAB][TAB]// lambda body | |
|[TAB]|[TAB]}); | |
|[TAB]|} | |
| +------------------------------+ |
|} |
+--------------------------------------+
+--------------------------------------+
|namespace foo |
|{ |
| +------------------------------+ |
|[TAB]|auto bar(args) | |
|[TAB]|{ | |
| | +----------+ | |
|[TAB]|[TAB]return baz(|[args](){ | | |
|[TAB]|[TAB][TAB] | ... | | |
| |[TAB] |} | | |
| | +----------+ | |
| |[TAB]); | |
|[TAB]|} | |
| +------------------------------+ |
|} |
+--------------------------------------+
+--------------------------------------+
|namespace foo |
|{ |
| +------------------------------+ |
|[TAB]|auto bar(args) | |
|[TAB]|{ | |
| | +----------+ | |
|[TAB]|[TAB]return baz(|[args](){ | | |
|[TAB]|[TAB] |[TAB]... | | |
| |[TAB] |} | | |
| | +----------+ | |
| |[TAB]); | |
|[TAB]|} | |
| +------------------------------+ |
|} |
+--------------------------------------+
To clarify, I do not have a problem; I'm simply revealing the existence of certain requirements in the wild.
The 1960's tab modeled after typewriter tab stops is not up to snuff to these requirements.
You fall back on spaces, and then you have a half-baked result where only some of the indentation scales with the tab size.
I suspect that a successful solution will not involve tabs at all. It's algorithmically possible for the text presentation tool, such as the editor, to infer which spaces are indentation and which are alignment, informed by the language syntax, and then allow the indentation spaces to have a configurable size.
I posited that if tabs had simple expansion semantics (tab produces fixed number of spaces starting at any position) that would also be workable. Unfortunately, it requires integration into way too many tools all at the same time.
The 1960's tab modeled after typewriter tab stops is not up to snuff to these requirements.
You fall back on spaces, and then you have a half-baked result where only some of the indentation scales with the tab size.
I suspect that a successful solution will not involve tabs at all. It's algorithmically possible for the text presentation tool, such as the editor, to infer which spaces are indentation and which are alignment, informed by the language syntax, and then allow the indentation spaces to have a configurable size.
I posited that if tabs had simple expansion semantics (tab produces fixed number of spaces starting at any position) that would also be workable. Unfortunately, it requires integration into way too many tools all at the same time.
[deleted]
[deleted]
> I'm not sure how good the editor support is for this; on a team of 15, you will easily find two who will mess this up often enough that the team's adjustable tab dream will crumble.
Run things through a linter.
Run things through a linter.
The second example is avoidable by forbidding mixed use of tabs and spaces, as in the two directly following each other. The first example doesn't do what you want really as x and y are part of the commented out code.
The second example requires a careful mix of leading indentation tabs followed by alignment spaces in order to work correctly: so the editing user can vary the tab size locally, while seeing the correct alignment.
If you forbid the mixed leading tabs and spaces, while insisting on tabs for indentation, then you're ruling out code formatting styles which exhibit such alignment.
That's a worse position that banishing tabs, because you are dictating code formatting ideologies for the sake of your indentation method.
The situation of tabs being banished does not, by itself, dictate to what the code should look like.
If you forbid the mixed leading tabs and spaces, while insisting on tabs for indentation, then you're ruling out code formatting styles which exhibit such alignment.
That's a worse position that banishing tabs, because you are dictating code formatting ideologies for the sake of your indentation method.
The situation of tabs being banished does not, by itself, dictate to what the code should look like.
This suggests that spaces are more popular.
https://hoffa.medium.com/400-000-github-repositories-1-billi...
The only exceptions being C, where tabs are slightly more common, and Go, where tabs are the official style.
https://hoffa.medium.com/400-000-github-repositories-1-billi...
The only exceptions being C, where tabs are slightly more common, and Go, where tabs are the official style.
It's amusing to see this on HN. I always preferred TABs, but for most of my SW programming life I've been told to prefer spaces. I'm actually surprised to hear folks here preferring TABs - I first read your comment as humor. Perhaps the pendulum has shifted (again)?
Back when the Tab character was first invented, the indentation was always to a multiple of the 8th column; there was no option for anything else. Not sure why anyone thinks living 50 years in the past is a good idea.
Because, the tab being fixed at some specific, agreed-upon value is better than it being a moving target.
If you use tabs in a plain text document, you know what they are going to do because of the 8 space tab de facto standard.
You could also know what tabs are going to do in a plain text document, if plain text had a standard way to program the tab size. To say, okay, in this line, we have 4 space tabs. Or these specific tab stops at these columns.
But here is no such standard thing; therefore, any tab size option ends up being something that is outside of the representation of the text. It's a setting in the text editor, or terminal or rendering software (e.g. monospaced text to ps/pdf).
The user has to somehow find out what tab size the text "wants", and then configure it. And that tab size fiddling is a sucky waste of time everyone hates; why can't the text just assume 8 so the default works?
If you use tabs in a plain text document, you know what they are going to do because of the 8 space tab de facto standard.
You could also know what tabs are going to do in a plain text document, if plain text had a standard way to program the tab size. To say, okay, in this line, we have 4 space tabs. Or these specific tab stops at these columns.
But here is no such standard thing; therefore, any tab size option ends up being something that is outside of the representation of the text. It's a setting in the text editor, or terminal or rendering software (e.g. monospaced text to ps/pdf).
The user has to somehow find out what tab size the text "wants", and then configure it. And that tab size fiddling is a sucky waste of time everyone hates; why can't the text just assume 8 so the default works?
The best reason I've seen for tabs is this one [0], where there were two people working on the same code base with different visual impairments, where one person needed 1 space tabs with a very large font and the other had to use 8 space tabs with a very wide monitor. You can't get that functionality if you assume any tab width.
[0] https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
[0] https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
I read that bit about the two developers also. It was never explained what the 8-space indent person's visual impairment might be; I suspect that it's a field of vision problem: difficulty tracking vertically between distant elements that are expected to be at the same indentation level. Editors can help here by rendering some vertical lines to guide the eyesight. Nobody should have to resort to huge tabs because of a vertical tracking problem.
I really think solving the adaptive indentation problem with tabs is a nonstarter. You have to adapt the tools to the reams of existing code, not vice versa.
The editor, in combination with recognizing the syntax of the language to some extent, could treat leading indentation spaces in a flexible "tab like" way. Indentation that is excessive to the visually impaired developer could be reduced by assigning fractional widths to just leading spaces, like 1/8, 1/4 or 1/2 a cell. The editor has to separate indentation spaces from alignment spaces for this purpose.
Another approach could be that, quite simply: the editor groks the indentation and renders it flexibly. It deduces that a certain line of code is three levels indented and then renders that however the user wants, regardless of whether the three levels come from three tabs, 24 spaces, or a mixture of tabs or spaces or whatever.
If the editor knows that two space indentation is in effect, and some line with 30 spaces is deduced to be at four indentation levels, then it knows that eight spaces of that line are rendered as abstract indentation, and the remaining spaces are literal, for alignment.
This is not some Hard Problem in software where we have to throw our hands in the air and conclude that the only way is to achieve the requirements is to have tabs in the data.
I really think solving the adaptive indentation problem with tabs is a nonstarter. You have to adapt the tools to the reams of existing code, not vice versa.
The editor, in combination with recognizing the syntax of the language to some extent, could treat leading indentation spaces in a flexible "tab like" way. Indentation that is excessive to the visually impaired developer could be reduced by assigning fractional widths to just leading spaces, like 1/8, 1/4 or 1/2 a cell. The editor has to separate indentation spaces from alignment spaces for this purpose.
Another approach could be that, quite simply: the editor groks the indentation and renders it flexibly. It deduces that a certain line of code is three levels indented and then renders that however the user wants, regardless of whether the three levels come from three tabs, 24 spaces, or a mixture of tabs or spaces or whatever.
If the editor knows that two space indentation is in effect, and some line with 30 spaces is deduced to be at four indentation levels, then it knows that eight spaces of that line are rendered as abstract indentation, and the remaining spaces are literal, for alignment.
This is not some Hard Problem in software where we have to throw our hands in the air and conclude that the only way is to achieve the requirements is to have tabs in the data.
These days our editors are already doing a huge amount of parsing of our code. I know I've seen one editor, probably Visual Studio, that can determine your nesting level and draw vertical lines to delineate it.
I don't think 8 characters was ever an official standard, just a de facto one. The problem is that it's too large for most modern use cases.
These days I find myself using smart editors that combine auto-indenting with tab-to-space conversion. You won't find a tab character in any of my files.
These days I find myself using smart editors that combine auto-indenting with tab-to-space conversion. You won't find a tab character in any of my files.
> it's too large for most modern use cases.
That's just opinion, though; some lunatics think that 8 space indentation is just fine, and they control what goes into the Linux kernel.
Basically, either you think 8 space indentation is fine, or else you regard 8 character tabs as not being suitable for the indentation use case (either you write off the tab entirely, or else subdue its size).
It has nothing to do with modern; programmers revolted at 8 space indentation in 1980 also. Indentation of less than 8 is not a modern trend.
Case study: V6 Unix, 1975.
C compiler uses hard tabs for indentation:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/...
(Was that viewed as 8 spaces though, when edited?)
When we look at Yacc in the same release, we see the germination of the problem of mixed style. Part of the source uses two space indentation. Part of it uses hard tabs. Other conventions also differ:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/...
Yikes! That's exactly the sort of thing that leads to tabs being banned.
> You won't find a tab character in any of my files.
I could almost say the same, except (1) rare accidents happen and (2) some of them are makefiles.
That's just opinion, though; some lunatics think that 8 space indentation is just fine, and they control what goes into the Linux kernel.
Basically, either you think 8 space indentation is fine, or else you regard 8 character tabs as not being suitable for the indentation use case (either you write off the tab entirely, or else subdue its size).
It has nothing to do with modern; programmers revolted at 8 space indentation in 1980 also. Indentation of less than 8 is not a modern trend.
Case study: V6 Unix, 1975.
C compiler uses hard tabs for indentation:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/...
(Was that viewed as 8 spaces though, when edited?)
When we look at Yacc in the same release, we see the germination of the problem of mixed style. Part of the source uses two space indentation. Part of it uses hard tabs. Other conventions also differ:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/...
Yikes! That's exactly the sort of thing that leads to tabs being banned.
> You won't find a tab character in any of my files.
I could almost say the same, except (1) rare accidents happen and (2) some of them are makefiles.
This is why I don't use tabs, and instead use 2 spaces for indentation like a sane and reasonable person.
I cowardly use tabs viewed as 2 spaces so if needed in the future some quick lazy code like sed can convert it to 4 spaces or something if someone demands.
I haven't seen any poll results (yet!), but I bet we're in a pretty small minority. Two spaces is jist what i find most aesthetically pleasing. Four seems to be the standard among my peers, and the apparent fact that the standard is historically eight boggles my mind.
Well, it was (kind of) a joke about "sane and reasonable" because everyone seems to have their favorite reasons for preferring one way or another.
I agree about it being aesthetically pleasing. For me it's the easiest spacing to read and scan code horizontally and diagonally.
And apparently:
> using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience.
https://stackoverflow.blog/2017/06/15/developers-use-spaces-...
I agree about it being aesthetically pleasing. For me it's the easiest spacing to read and scan code horizontally and diagonally.
And apparently:
> using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience.
https://stackoverflow.blog/2017/06/15/developers-use-spaces-...
The ideal tabbing scheme is fibonacci. If you can't do that, 8 will do.
1, 1, 2, 3? Seems like too small an increment scheme.
Minor /s here. Inaccuracy in specifications lead to inaccuracies in code.
Minor /s here. Inaccuracy in specifications lead to inaccuracies in code.
The first couple indents don't really need much anyway... Especially if you're writing something like the C# example elsewhere in the thread.
if (CompareTag("Player")) in that example is 24 characters in from the side, but four would really feel better.
If you're using a language that's less indenty, maybe you want to start further on in the sequence.
Although, in all honesty, I've never used fibonacci tabs, it's just something to suggest to move the discussion elsewhere. :D
if (CompareTag("Player")) in that example is 24 characters in from the side, but four would really feel better.
If you're using a language that's less indenty, maybe you want to start further on in the sequence.
Although, in all honesty, I've never used fibonacci tabs, it's just something to suggest to move the discussion elsewhere. :D
Fibonacci? Never! Golden ratio with fractional spaces. With fibonacci someone is always going to screwup the whitespace. :p
It's awfully useful for detecting indentation errors. Everyone uses 4, so anything that uses something else will make it obvious when someone has borked up the whitespace (which always seems to happen on projects that use tabs).
The choice isn't really "tabs vs spaces", it's "(tabs and spaces) vs (spaces)". And 8 char indentation is ludicrous.
Ludicrous, nope, it's the standard. See: linux kernel.
To quote from the coding style:
"Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3."[1]
If it works for a multi-million line C code base like the linux kernel withou any real problem, then it's definitely not ludicrous.
If you find yourself indenting too much, then write some helper functions.
[1] https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
"Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3."[1]
If it works for a multi-million line C code base like the linux kernel withou any real problem, then it's definitely not ludicrous.
If you find yourself indenting too much, then write some helper functions.
[1] https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
What the linked thread doesn't mention is that github respects editorconfig files. If you create one in your repo and set the number of spaces a tab should represent, it uses that as default for the repo. Maybe the feature hadn't been launched yet in 2018?
https://editorconfig.org/
https://editorconfig.org/
Wow, the linked discussion turned toxic pretty fast for something so trivial. It's surprising no one in that thread mentioned that there is a good reason to keep it the way it is, namely to avoid screwing up the formatting of files on GitHub by sticking to an ages-old, well-known default.
Looks like this thread is devolving into a tab vs space war again, an eternal holy war without end except at local level where some VP of engineering put down a decree one way or another and the plebs begrudgingly follow.
"Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you’ve been looking at your screen for 20 straight hours, you’ll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning."
[1]: https://www.kernel.org/doc/html/v4.10/process/coding-style.h...