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

[kris]

pragma wrote:
> 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
> 


Hrm. Too many darned Returns ....

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 ~ even better!