No you can't, because material that is aligned between lines that have different indentation gets screwed.
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 */
};
Only the x and y lines moved when the tab size changed, so the comment is 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:
{
function(arg, arg,
arg, arg);
}
OK, this will work if we use exactly one tab for both lines, and then spaces for aligning the arguments:
{
[Tab]function(arg, arg,
[Tab] arg, arg);
}
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.
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.
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:
OK, this will work if we use exactly one tab for both lines, and then spaces for aligning the arguments: 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.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.