[OT] Auto code reformating / one coding style enforcment.

[pragma]

kris wrote:
> Pragma wrote:
>> Unknown W. Brackets wrote:
>>
>>> In my code, I use hard tabs for everything and set my tab-width to 4 
>>> spaces.
>>>
>>> I've never had trouble with printing code (something I do less often 
>>> than have birthdays, mind you) nor any text editor displaying my code 
>>> weirdly.
>>>
>>> Some people hate hard tabs, because they just have to line things up 
>>> after a non-tab character with tabs.  I think this is a Bad Thing 
>>> (TM), but if you have to do it, I understand using spaces.
>>>
>>> But I've never seen a case where a program would misbehave if the tab 
>>> width was not set to 8.... I just can't wrap my head around the 
>>> benefit of using both tabs *and* spaces.
>>>
>>> -[Unknown]
>>>
>>>
>>>> Unknown W. Brackets wrote:
>>>>
>>>>> Uh-huh, sure.
>>>>>
>>>>> You're usually right, but I don't like having to hit backspace four 
>>>>> times or 1 time alternatively based on my indentation level.  
>>>>> That's just bizarre.  I've never seen someone mix tabs like that 
>>>>> before...
>>>>>
>>>>> Why do you prefer it, if I may ask?
>>>>>
>>>>> -[Unknown]
>>>>>
>>>>>
>>>>>> It works just fine when you set tabs to be 8 characters, as god 
>>>>>> intended them to be.
>>>>
>>>>
>>>>
>>>> Because it isn't screwed up when you type it to the screen or the 
>>>> printer.
>>
>>
>> For what it's worth, I think Sean is talking about code like this:
>>
>> switch(x){
>>     case 'foo':        break; // 2 tabs
>>     case 'something':    break; // 1 tab
>> }
>>
>> On my display, with tab=8 spaces in Thunderbird, the 'break' 
>> statements all line up perfectly. If your viewer has it set to 
>> something else (say 4 spaces), it doesn't look right.  So its the 
>> /internal/ indentation that fails here, as the left column will always 
>> look clean.
>>
>> IMO, this is what code beautifiers are for.  I'm not going to worry 
>> about inconsistent tabbing and spacing in any of my projects until 
>> release time comes around anyway. ;)
> 
> 
> 
> Yes ~ I vote that all D code should strictly avoid the use of *any* 
> indentation :D

Better yet, why don't we just make 'indent' a keyword?  Then there'll be 
no mistaking exactly how much whitespace there is supposed to be!

void main(){
indent uint x;
indent writefln("X is: %d",x);
}

Hrm... carriage returns can be kind of inconsistent between platforms 
too.  Let's fix that with 'newline' while we're at it.

newline;
class Foobar{ newline
indent this(){ newline;
indent(2) /*do nothing*/ newline;
indent } newline
} newline;

Better, but spacing could wind up inconsistent too.  That's easy enough 
to fix: the spec says that '__' is reserved, so we'll just use that 
instead of space:

uint__factorial(uint__x){__newline
indent()if(x__<=__1){newline
indent(2)__return__1__newline;
indent}newline
indent()else{newline
indent(2)return__x__*__factorial(x-1)__newline;
indent}newline
}newline;

There, much better! :-P