August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | Regan Heath wrote:
> On Mon, 14 Aug 2006 09:14:04 -0700, Sean Kelly <sean@f4.ca> wrote:
>>
>> Hard tabs work okay for leading indentation, but for inner indentation--long function calls, if statements, variable lists, etc--they can render code unreadable if viewed with a different tab width. Even worse is if in a group project, some people use hard tabs and others spaces, and those using hard tabs have different tab widths.
>
> Simple; don't use hard tabs for internal* spacing, only for leading indentation. Use spaces for internal spacing.
>
> * meaning in the middle of a line of text.
Doesn't work with the way I format code. See my other post for an example.
Sean
|
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | Brad Roberts wrote:
> Are we really having this debate. Might as well start on editor wars and who's languages is better than.. oh wait, this is a D forum, so at least we can skip _that_ one.
>
> There's got to be better ways to expend this sort of energy. :)
"Kids: just say *no* to Indentation"
|
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | Sean Kelly wrote: > Derek Parnell wrote: > >> On Mon, 14 Aug 2006 18:24:05 +0200, Oskar Linde wrote: >> >> >> >>> This is how Emacs works and has worked for ages. Tabs are not directly used for indentation, but rather for optimizing the number of spaces needed. I guess at some time in the past, those 7 bytes saved here and there were well worth it. It would probably improve output speed on old teletypes and save memory at the same time. Those old teletypes could not redefine the tab stops anyway (well, I know the modern vt100 could, but not the vt52 afaik), so any other use for the tab character wasn't realistic. >>> >>> Today, the benefits are not as clear... :) >> >> >> Thus my reference to "being locked into the past". The need for this style >> is no longer needed and hasn't been needed for quite awhile now. But >> habits, good and bad, are hard to break. > > > With emacs, breaking this particular bad habit is as simple as (setq-default indent-tabs-mode nil) :-) > > Sean <sarcasm>Yeah that would've been the first command I'd have typed in when I entered emacs as a complete n00b, after figuring out how to enter emacs-LISP commands in the first place.</sarcasm> -- Regards, James Dunne |
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to pragma | 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 > Apparently you _can't_ turn off stupid. :) -- Regards, James Dunne |
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to pragma | 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! |
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | I'm assuming you have some interest in this conversation since you responded. I mean not to encourage or start a flame war, but I fear I have (again; I think I've done this before!) asked a tricky question.... just wanted to know, mainly. Anyway, it really is a shame that tab stops in <pre> are, according to the spec, 8 characters in width. Of course, the spec also says not to use them: http://www.w3.org/TR/html4/struct/text.html#h-9.3.4 Anyway, it's typically trivial to replace tabs with spaces in such code sections. Since tabs should only be used in sequence from the left gutter (if you plan for them to line up), this is trivial. When printing, I believe many text editors do send to the printer as spaces (not tabs.) Perhaps I am mistaken. I follow the rule described, and it never causes me problems. I simply never line things up. I use tabs only for indentation, and spaces for lining things up. Anything else causes problems. -[Unknown] > Regan Heath wrote: >> On Mon, 14 Aug 2006 10:27:11 -0700, Walter Bright <newshound@digitalmars.com> wrote: >>> Frits van Bommel wrote: >>>> Oh, and if you prefer 8-space indentation, I'd like to suggest you use hard tabs (consistently!) so others can easily view it at 4 spaces (or whatever their personal preference may be). >>> >>> My screen ain't wide enough for that. >> >> Sure it is. Your preference is for 4 space wide indentation, all you have to do is tell your editor to display a hard tab as 4 spaces (as any editor worth it's salt can do) and use hard tabs everywhere. >> >> Problem #1 solved. >> >> In fact, if you do this and discover some code is too wide for 4 space indentation, simply set tabs to 2 spaces (temporaily) to read that code, then set it back. Isn't that nice? and flexible? >> >> I suspect if you print this code, and the editor sends actual hard tabs to the printer they'll probably be 8 spaces wide.. but: >> 1. who prints code?!? > > I do. I also put code in html <pre>...</pre>, where tabs are 8. I put code in emails, where tabs are 8. I print code on the console, where tabs are 8. I send code to other operating systems, where tabs are 8. > >> 2. the editor _should_ instead send your specified # of spaces instead of hard tabs. >> >> Problem #2 solved. > > Send it to where? The disk file? Then there aren't tabs in it anymore. > >> Oh, and for those who want to align text on seperate lines remember the golden rule; "hard tabs first, spaces following" and you'll have no problems. Regardless of the viewers tab width the lines will align. (ignoring non fixed-width fonts, for which no solution involving spaces/tabs will work). >> >> Problem #3 solved. > > Not really, because I follow that rule, and if tabs are set to 3 it gets all screwed up. |
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Dunne | James Dunne wrote:
> Sean Kelly wrote:
>> Derek Parnell wrote:
>>
>>> On Mon, 14 Aug 2006 18:24:05 +0200, Oskar Linde wrote:
>>>
>>>
>>>
>>>> This is how Emacs works and has worked for ages. Tabs are not directly used for indentation, but rather for optimizing the number of spaces needed. I guess at some time in the past, those 7 bytes saved here and there were well worth it. It would probably improve output speed on old teletypes and save memory at the same time. Those old teletypes could not redefine the tab stops anyway (well, I know the modern vt100 could, but not the vt52 afaik), so any other use for the tab character wasn't realistic.
>>>>
>>>> Today, the benefits are not as clear... :)
>>>
>>>
>>> Thus my reference to "being locked into the past". The need for this style
>>> is no longer needed and hasn't been needed for quite awhile now. But
>>> habits, good and bad, are hard to break.
>>
>>
>> With emacs, breaking this particular bad habit is as simple as (setq-default indent-tabs-mode nil) :-)
>
> <sarcasm>Yeah that would've been the first command I'd have typed in when I entered emacs as a complete n00b, after figuring out how to enter emacs-LISP commands in the first place.</sarcasm>
*snort* I'll admit emacs is pretty non-intuitive, but this is a setting I inherited from my first .emacs file and it's been present ever since.
Sean
|
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dawid Ciężarkiewicz | Dawid Ciężarkiewicz wrote: > My thoughts are always like this: why creators of C language allowed people > to format code freely? Wouldn't world be a better place if languages would > enforce their one-true-coding-style? If there would be no choice there > would be no reason to argue. Because There Is More Than One Way To Do It (TIMTOWTDI) ? I had my hard tabs at 4, because of my Macintosh upbringing, but in UNIX they have always been at 8 (so now I use spaces) > [...] > > What do you think? I like choice. --anders PS. I don't understand the "it would better if we only had one D compiler" or "it would be better if we only had one official GUI library" either. |
August 15, 2006 Re: [OT] Auto code reformating / one coding style enforcment. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dawid Ciężarkiewicz | Dawid Ciężarkiewicz wrote: > /me is dreaming about kind of public agreement: > > "We - the D users - when coding in D will always reformat it using style > described: <a href="somelink">here</a> even when we personally think it's > not perfect/best/favorite style and will be strongly advicing anybody who > codes in D to do so as well." Yeah, but I can't really see that happening... "We, the undersigned, promise to leave our hard tabs at 8 and use both hard tabs and spaces for four step indentation as we set fit." > However I have a doubts that such group effort could succeed in language > with C-like syntax. Too many people coming from different places with > different habits. > > Even phobos sources have mixed space/tabs indentation (mixed in single > file!) ... sad. "Sad" doesn't sound like a step to the above :-) Walter's indentation style advocates doing just that, mixing them. And I guess it *is* the offical style, for both of DMD and Phobos ? --anders |
August 15, 2006 RFC 451 (was [OT] Auto code reformating / one coding style enforcment) | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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! |
Copyright © 1999-2021 by the D Language Foundation