Four instead of eight spaces for tabs

[LB]

Catfish666 wrote:

And you have to be very careful to successfully write tab-size agnostic code which is pretty regardless of tab settings. You can forget about splitting up if() conditions onto multiple lines, among other things.

How is it difficult at all? Tabs are primary indentation, spaces are internal indentation. Changing the tab size doesn't affect any of the internal alignment of the code. Try it on some of my tab-indented code ;p

[Disch]

How is it difficult at all? Tabs are primary indentation, spaces are internal indentation. Changing the tab size doesn't affect any of the internal alignment of the code. Try it on some of my tab-indented code ;p

How many people actually consistently make that distinction?

I have never in my life seen pretty print code that made the necessary distinction between primary tabs and internal spaces. It's a natural habit for the user to just hit tab to get the cursor where you want.

Example:

void func()
{
         if( something      )       doSomething();
    else if( something_else )       doSomethingElse();
    else if( something3     )       doSomething3();
    else                            doTheLastThing();
}

To do this this properly with spaces:
Hit tab or space. Impossible to get wrong.


To do this properly with tabs:
1) First indentation up to the 'else' line has to be a single tab
2) On the line with the first 'if'... you have to have 1 tab, followed by 5 spaces.
3) The whitespace between the closing parenthesis and the function calls have to be all spaces - can't have any tabs.
4) Ditto for the whitespace before the closing parenthesis


Getting tabs right is convoluted. And you don't even notice when you get it wrong. It's not until you post code somewhere or give the code to someone else where they notice it all got screwed.

Spaces, on the other hand, always work. Wherever.. whenver... regardless of editor.. or settings.... the code will look how you want it to look.

If the user really doesn't like your indentation level, there are tools to change it.

[ne555]

That looks awful.
Also, the first `if' seems to be in another level.

> To do this this properly with spaces:
> Hit tab or space. Impossible to get wrong.
monkey work.

[Catfish666]

L B wrote:

Tabs are primary indentation, spaces are internal indentation. Changing the tab size doesn't affect any of the internal alignment of the code.

So you mix tabs and spaces. My gut feeling tells me that's wrong. Hopefully everybody else who edits your code doesn't get confused about the "internal indentation" so as to mess it up.

L B wrote:

Oh, and I definitely don't want to argue tabs vs spaces - I'm just explaining why I use tabs to those of you who prefer spaces.

You don't prefer indent spaces any less than others do. It's just that you don't use them exclusively. Which in my opinion can easily lead to inconsistencies. But to each his own.

[LB]

@Disch @Catfish I don't "mix" tabs and spaces. Tabs are for indenting the code based on the {} blocks. Spaces are for aligning the code to make it pretty to read. You could argue that putting spaces around + and - is "mixing tabs and spaces" but that doesn't make any sense.

Disch:

void func()
{
	     if(something     ) doSomething();
	else if(something_else) doSomethingElse();
	else if(something3    ) doSomething3();
	else                    doTheLastThing();
}

[Peter87]

I totally agree with LB here. It would be even easier to get it right if code editors actually had a way to highlight space and tabs in different colours.

[Catfish666]

Peter87 wrote:

It would be even easier to get it right if code editors actually had a way to highlight space and tabs in different colours.

Some editors can be set to do this.
I remember that Kate and Geany can highlight "hard tabs" and spaces differently.
I'm pretty sure Sublime Text can too, if you dig deep enough in the configuration.

L B wrote:

@Disch @Catfish I don't "mix" tabs and spaces. Tabs are for indenting the code based on the {} blocks. Spaces are for aligning the code to make it pretty to read.

Maybe there's a misunderstanding.

When I say "you mix tabs and spaces" I mean simply that you use both hard tabs and spaces in the same source code, instead of using either one of them exclusively, as in only spaces or only tabs (which are not inserted as spaces).

So you do mix them.

[Disch]

ne555 wrote:

That looks awful.

I disagree. Everything is cleanly aligned in columns. It makes it clear not only to see the similarities between all the lines, but also the subtle differences.

Also, the first `if' seems to be in another level.

It's aligned with the other ifs.

monkey work.

What?


But that's just one example. Another example might be in a class definition:

class Foo
{
public:
    void            foo();
    int             bar();
    std::string     baz();
};

Same issue here. If you want the function names aligned like this, you have to use spaces for the whitespace between the return type and the function name.

And another example of a switch statement (this one is real, from an actual program I wrote recently):

            switch(op)
            {
                /* Branches */
            case 0x10:      AdBrch( (cpu.fNZ & 0x180) == 0 );   break;  /* BPL  */
            case 0x30:      AdBrch( (cpu.fNZ & 0x180) != 0 );   break;  /* BMI  */
            case 0x50:      AdBrch(  cpu.fV           == 0 );   break;  /* BVC  */
            case 0x70:      AdBrch(  cpu.fV           != 0 );   break;  /* BVS  */
            case 0x90:      AdBrch(  cpu.fC           == 0 );   break;  /* BCC  */
            case 0xB0:      AdBrch(  cpu.fC           != 0 );   break;  /* BCS  */
            case 0xD0:      AdBrch( (cpu.fNZ & 0x0FF) != 0 );   break;  /* BNE  */
            case 0xF0:      AdBrch( (cpu.fNZ & 0x0FF) == 0 );   break;  /* BEQ  */

                /* Flag Flip-flopping */
            case 0x18:      AdRdIp();   cpu.fC = 0;             break;  /* CLC  */
            case 0x38:      AdRdIp();   cpu.fC = 1;             break;  /* SEC  */
            case 0x58:      AdRdIp();   cpu.fI = 0;             break;  /* CLI  */
            case 0x78:      AdRdIp();   cpu.fI = 1;             break;  /* SEI  */

LB wrote:

Disch:

Yes yes, very nice. =P

I already knew you can do it with tabs. And in fact I gave step by step instructions of how it could be accomplished with tabs.

My point is not that this is impossible to do with the approach of primary indenting being tabs. My point is that if you use spaces, it literally is impossible to get wrong.

And actually typing it is usually much faster and easier. In your case... since the tab key inserts tabs... to add that whitespace after the else you must have either hit the space bar a couple dozen times... or you held it for 2+ seconds until it made a row full of them. Whereas for me, all I have to do it hit tab 4 times.


Furthermore... I literally have never seen code like this in the wild. Any pretty print code I've seen in libs I've looked at (or even in text files I've looked at) either has used spaces... or has erroneously assumed a specific tab width.

Very few people get it right with tabs. Maybe you're one of them... and that's great. But other people screw it up. Whereas nobody ever screws up spaces because it's impossible.

[LB]

Disch wrote:

Another example might be in a class definition:

class Foo
{
public:
    void            foo();
    int             bar();
    std::string     baz();
};

Same issue here. If you want the function names aligned like this, you have to use spaces for the whitespace between the return type and the function name.

The only issue here is that the alignment says the functions are related even though they might not be related at all.

Disch wrote:

And actually typing it is usually much faster and easier. In your case... since the tab key inserts tabs... to add that whitespace after the else you must have either hit the space bar a couple dozen times... or you held it for 2+ seconds until it made a row full of them. Whereas for me, all I have to do it hit tab 4 times.

I don't mind hitting the space key a lot to make the code look nice.

I just want to clarify to everyone: I never use tabs in my code after primary indentation. I never use spaces in my code before or during primary indentation.

Have a look at these:
https://github.com/LB--/hSDK/blob/Fusion-2.x/src/hSDK/Parameters.cpp#L13
https://github.com/LB--/hSDK/blob/Fusion-2.x/src/hSDK/Parameters.cpp#L32
https://github.com/LB--/hSDK/blob/Fusion-2.x/src/hSDK/Parameters.cpp#L129
Is that what you consider "mixing tabs and spaces"?

I am assuming Disch is actually talking about this:

		struct Enforce32bit
		<
			T, typename std::enable_if
			<
				sizeof(T) == 4
			 && !std::is_floating_point<T>::value
			 && !std::is_integral<T>::value
			 && !std::is_same<T, char_t *>::value
			 && std::is_pod<T>::value
			 && !std::is_reference<T>::value,
				void
			>::type
		> final
		{

Indeed, I too would consider this mixing tabs and spaces and is a mistake on my part that will be fixed.

[Disch]

LB wrote:

The only issue here is that the alignment says the functions are related even though they might not be related at all.

I would make that distinction by adding at least one empty line between groups of related functions.

Have a look at these:
[...]
Is that what you consider "mixing tabs and spaces"?

Those all look fine. And no, that's not what the issue I'm referring to.

I'm referring to this:

void some_code()
{
	int x = 0;		// some aligned comments here to add
	if( whatever == 5 )	//  flavor and/or
	{			//  descriptive context
		x = 10;		//  to this
	}			//  code
}

Or... as it looks in my editor:

http://imgur.com/MqNt5YO

(note I have it open as a txt file, hence the spelling underlines and lack of syntax highlighting... but you get what I'm getting at)


EDIT:

I don't mind hitting the space key a lot to make the code look nice.

Neither do I. It's just easier (and habit) to use tab since you don't have to press it as much. Particularly if there's a lot of whitespace between where you are and where you want to be.

I just want to clarify to everyone: I never use tabs in my code after primary indentation. I never use spaces in my code before or during primary indentation.

This is the only way to do hard tabs properly. So you're doing it right. Good on you.

My point is that most people don't do it right. Most people screw it up.

On the other hand... nobody ever screws up spaces because it's impossible.





EDIT 2:

We can go back and forth about this all day... but I think it comes down to this:

advantages to using tabs:
- Smaller file sizes.
- User can specify their own tab size even when reading others' code.

disadvantage to using tabs:
- Requires extra caution when making pretty-print aligned code


So it really comes down to personal preference as to which one you feel outweighs the other.

Personally, with the amount of alignment I put in my code... I feel the advantages to tabs are simply not worth the extra work involved.

Apparently, LB, you disagree.. and feel the extra work is trivial.

I don't really know if there's more that can be said on this. =P But it's a fun discussion anyway.

[LB]

Ah, yeah, I didn't realize that sidealong comments were susceptible to that. I don't really know a good way to fix that when using tab characters.

I will definitely agree that spaces make for less trouble, but my hands and fingers are used to tabs. I have a bad habit of using backspace to un-indent when I should use Shift+Tab, so when using spaces for indentation I will accidentally backspace a single space frequently and then have to backspace the other three or add it back. So, I guess the only real reason I use tabs is because I'm used to it more.

[3hM2Nwbp]

Is anyone still not using an ide that auto-indents based on your project configuration? Seems like a problem amongst the text editor command-line masochists to me.

[ne555]

>> Also, the first `if' seems to be in another level.
> It's aligned with the other ifs.

void func()
{
    while( some_condition )
        if( cond1 )  doSomething();
        else         other(); //compare with line 10

         if( something      )       doSomething(); //compare with line 4
    else if( something_else )       doSomethingElse();
    else if( something3     )       doSomething3();
    else                            doTheLastThing();
}

>> monkey work.
> What?
repetitive, boring, alienating work. Consider the case where another condition is added, so all the previous lines need to be adjusted.
I prefer to write code than to make it look pretty.

[chrisname]

LB wrote:

I have a bad habit

Well the good thing about bad habits is that you can change them.

[LB]

I agree with ne555 here, I would have all the if/else/while/for/etc start in the same column per indentation level.

As for the original purpose of this thread, I would like it if the forum CSS changed the tab width from its default to 4 just for the sake of not having people's code go off the edge of the post so often. There are still plenty of people who post their code on the forums using tabs and because the forum posts are so narrow it often goes off the side (and generally the people posting such code have excessive levels of nesting and indentation).

[Disch]

@ne555: Now that is ugly. A multiline loop without any braces? You'd have to be a madman or a sadist to do that.

repetitive, boring, alienating work. Consider the case where another condition is added, so all the previous lines need to be adjusted.
I prefer to write code than to make it look pretty.

It's not that hard to make your code look good... and it makes it MUCH easier for others (and your future self) to read. A little extra work now prevents headaches later.

The value of code clarity is tremendous.

[LB]

Disch wrote:

@ne555: Now that is ugly. A multiline loop without any braces? You'd have to be a madman or a sadist to do that.

His point still stands with the braces.

[Disch]

Not really... with the braces there's a clear divider:

void func()
{
    while( some_condition )
    {
        if( cond1 )  doSomething();
        else         other(); //compare with line 10
    }

         if( something      )       doSomething(); //compare with line 4
    else if( something_else )       doSomethingElse();
    else if( something3     )       doSomething3();
    else                            doTheLastThing();
}

EDIT:

But fine... if you don't like that style, this is the same idea:

    if     ( something      )       doSomething();
    else if( something_else )       doSomethingElse();
    else if( something3     )       doSomething3();
    else                            doTheLastThing();

The point is: alignment.