RFC 451 (was [OT] Auto code reformating / one coding style enforcment)

[kris]

kris wrote:
> 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!



D RFC 451: A Proposal To Save American Wrists and Minds
-------------------------------------------------------

It has recently been shown that extensive use of the space-character 
encourages spatial disorientation, conceptual difficulties, left-brain 
degradation, a general loss of well-being, and the historic "Repetitive 
Repetitive" syndrome. The tab-key was invented as a measure of concern 
for these conditions.

In order to enhance the longevity of one's wrists, sanity, and 
associated livelihood, we propose the same principal be applied to 
identifiers within the D language. For example, how many programs have 
more than 999 functions? For those that don't, it would surely be far 
simpler to identify functions with up to three digits instead of those 
silly long-winded names? Factorial, for instance: it should be called 
"173" instead, or "387". Far shorter and much easier to type!

Because of this, we submit that D should allow identifiers to begin with 
a numeric character. Numeric literals, since they are relatively seldom 
used, should be prefixed to isolate then.

Since all identifiers can use short groups of digits instead of those 
ridiculous long names, we can reserve the common 26 letters of the 
alphabet for special language idioms: the 'newline' keyword (above) 
should be shortened to a simple 'n', since we'll all know what that 
stands for; 'indent' should become 'i' also, to simplify things in the 
same manner. The letter 'l' should be used to prefix literals.


u__173(u__0){__n__i()f(0__<=__l1){n__i(2)__r__1__n;i}n__i()e{n__i(2)r__0__*__173(0-l1)__n;i}n__}n;


Ahh ... isn't that so much more appropriate? Those left-wing lunatics 
with their extensive use of whitespace and so-called 'meaningful' 
identifier-names ... they're just so full of it.

Be a real programmer! Be a real man! Let's drop all that nonsense and 
vote for RFC '451'; save the wrists and minds of millions of real, live 
Americans!

Vote '451' today!