www.digitalmars.com         C & C++   DMDScript  

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

reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
This is *not* proposition of D change. Only free concept that I wish to
share with D users.

Most of the time of my coding work I'm dealing with code that I didn't
wrote. What is most irritating is when I just can't reformat code using
indent or astyle because I need to work on little change and produce diff
that will fit into original repository. And sometimes code is completely
mess - I don't care if someone likes breaking brackets here and there,
but ... I thing you all know what I'm talking about.

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.

"If I'd write my own language ..." (don't get it too serious - it's only
hypothetical ;-) ) there would be no way to code same code in two different
ways (except of identifier names, comments and such ...). There would be
one standard and compiler would enforce it - throwing errors about code
formating or even reformat code in the fly if asked to (optional switch or
something like that).

The users would have to adopt to code in such language - get used to one
coding style, which probably wouldn't be what they were doing before in
every aspect, but ...

... after some time they would discover that when they look at someone else
code in that language - there is no difference. Working with patch/diff
tools is nicer, reading code pleasure is bigger. Everything is better ...

Python code tries to enforce coding style rules - I like that aspect of it.
What I don't like is not enforcing to use tabs for indentation and which is
even worse - not enforcing on _any_ standard about indentation, only to be
consistent in whole source file. Except that I'm not aware of any language
(except Whitespace ;-) ) that do something similar. Have anybody even
tried? Did such language succeed?

What do you think?
Aug 12 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dawid Ciezarkiewicz" <dawid.ciezarkiewicz gmail.com> wrote in message 
news:eblf6h$1vo6$1 digitaldaemon.com...


 Most of the time of my coding work I'm dealing with code that I didn't
 wrote. What is most irritating is when I just can't reformat code using
 indent or astyle because I need to work on little change and produce diff
 that will fit into original repository. And sometimes code is completely
 mess - I don't care if someone likes breaking brackets here and there,
 but ... I thing you all know what I'm talking about.

 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.


I always thought it'd be cool if there were an IDE which could read in code, 
parse it into tokens, then display the tokens in any format you wished, and 
you could change things like indentation, spacing, bracket styles etc.  Then 
when you saved, it'd write it back out as a text file.  Of course, like you 
said, when dealing with things like diffs for repositories, you can't really 
do that..


 "If I'd write my own language ..." (don't get it too serious - it's only
 hypothetical ;-) ) there would be no way to code same code in two 
 different
 ways (except of identifier names, comments and such ...). There would be
 one standard and compiler would enforce it - throwing errors about code
 formating or even reformat code in the fly if asked to (optional switch or
 something like that).

 The users would have to adopt to code in such language - get used to one
 coding style, which probably wouldn't be what they were doing before in
 every aspect, but ...

 ... after some time they would discover that when they look at someone 
 else
 code in that language - there is no difference. Working with patch/diff
 tools is nicer, reading code pleasure is bigger. Everything is better ...


Most Basic languages are pretty much this way.  Whitespace and newlines are 
a lot more significant, and as such, you can pretty much only write 
constructs one way.


 Python code tries to enforce coding style rules - I like that aspect of 
 it.
 What I don't like is not enforcing to use tabs for indentation and which 
 is
 even worse - not enforcing on _any_ standard about indentation, only to be
 consistent in whole source file. Except that I'm not aware of any language
 (except Whitespace ;-) ) that do something similar. Have anybody even
 tried? Did such language succeed?

 What do you think?


I think you're on target with the idea that it's stupid to have such a 
freeform language style.  All that happens is everyone develops their own 
styles and everyone gets into religious debates about which is better.  In 
other words, it's a lot of argument over nothing.

What seems to be the most common solution to this problem is that 
programming teams / companies will often adopt a single coding style.  To 
this end, it would be very useful if there were a "dtidy" tool that everyone 
would have to run on their code before submitting it to everyone else.  This 
tool would optimally be powerful on its own, but with scriptability so that 
really obscure coding styles (like lining up braces with the left paren of 
the owning construct.. wtf) could still be generated.  Or, this tool would 
just look at the input and complain if it doesn't match the given coding 
style spec.  Kind of like a style lint tool.

Oh, and spaces should die.  Hard tabs for LIFE.
Aug 12 2006
prev sibling next sibling parent reply kris <foo bar.com> writes:
Dawid Ciężarkiewicz wrote:

 This is *not* proposition of D change. Only free concept that I wish to
 share with D users.
 
 Most of the time of my coding work I'm dealing with code that I didn't
 wrote. What is most irritating is when I just can't reformat code using
 indent or astyle because I need to work on little change and produce diff
 that will fit into original repository. And sometimes code is completely
 mess - I don't care if someone likes breaking brackets here and there,
 but ... I thing you all know what I'm talking about.
 
 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.



lol ... because there would never be a unanimous concensus on what that 
format should be ;D

You may recall the beating Fortran took because of the need to place 
variable-decls on the sixth column only (or something like that).

Python uses syntactically significant indentation (for blocks), instead 
of braces. Because of that, the language attracts a lot of flack from 
various quarters.




 "If I'd write my own language ..." (don't get it too serious - it's only
 hypothetical ;-) ) there would be no way to code same code in two different
 ways (except of identifier names, comments and such ...). There would be
 one standard and compiler would enforce it - throwing errors about code
 formating or even reformat code in the fly if asked to (optional switch or
 something like that).
 
 The users would have to adopt to code in such language - get used to one
 coding style, which probably wouldn't be what they were doing before in
 every aspect, but ...
 
 ... after some time they would discover that when they look at someone else
 code in that language - there is no difference. Working with patch/diff
 tools is nicer, reading code pleasure is bigger. Everything is better ...
 
 Python code tries to enforce coding style rules - I like that aspect of it.
 What I don't like is not enforcing to use tabs for indentation and which is
 even worse - not enforcing on _any_ standard about indentation, only to be
 consistent in whole source file. Except that I'm not aware of any language
 (except Whitespace ;-) ) that do something similar. Have anybody even
 tried? Did such language succeed?
 
 What do you think? 



As long as anyone considers writing code to be an "expression" or "art 
form", to any degree, the notion of a single writing format (upon which 
everyone will agree) is doomed to failure :)

There have been strict rules regarding the use of grammar, prose, and 
sentence structure for centuries ... yet, it seems those are abandoned 
on an accelerating basis :p
Aug 12 2006
parent reply renox <renosky free.fr> writes:
kris wrote:

 Python uses syntactically significant indentation (for blocks), instead 
 of braces. Because of that, the language attracts a lot of flack from 
 various quarters.


Note that one reason that Python get some flacks as dawid ciezarkiewicz 
rightly put it is that it doesn't enforce *enough* the syntax: blanks 
and tabs are 'equivalent', which makes a mess when you have various 
contributors..

If a language enforce 'syntactically significant indentation', it should 
  also enforce the use of tab instead of space for example.

Of course if one programmer is dumb enough to align with space, you 
could look for the error in the code for hours without finding the 
error, but this is easy to avoid: the compiler/interpreter should 
complain each time he see '4 space' or a tabulation depending of the 
choice of the delimiter.

Regards,
RenoX
Aug 13 2006
parent kris <foo bar.com> writes:
renox wrote:

 kris wrote:
 

 Python uses syntactically significant indentation (for blocks), 
 instead of braces. Because of that, the language attracts a lot of 
 flack from various quarters.


 
 
 Note that one reason that Python get some flacks as dawid ciezarkiewicz 
 rightly put it is that it doesn't enforce *enough* the syntax: blanks 
 and tabs are 'equivalent', which makes a mess when you have various 
 contributors..


yes; you're right



 
 If a language enforce 'syntactically significant indentation', it should 
  also enforce the use of tab instead of space for example.
 
 Of course if one programmer is dumb enough to align with space, you 
 could look for the error in the code for hours without finding the 
 error, but this is easy to avoid: the compiler/interpreter should 
 complain each time he see '4 space' or a tabulation depending of the 
 choice of the delimiter.
 
 Regards,
 RenoX
Aug 13 2006
prev sibling next sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
 What do you think? 


I think so too.
Sure, I have my own style and don't like any other ;)

Perhaps it would be good to have a formatting tool with 2-3 fixed style
sets, that it can use.

What I really miss, is a D indent tool that really works. I spent some
time on the dparser and even had some success with indenting code, but I
didn't continue.

I feel there should be much more man power in the dparser project. The
compiler itself should be build in D. It should provide a really good
interface for applications working with D code. And it should be build
in a way, that after parsing every bit of information is available, and
the source file can be regenerated with it.

That would enable many development tools for D.
Indention/autocompletion/refactoring/d-lint/...

well dreams ...
Aug 12 2006
parent reply Ben Gardner <bengardner.uncrustify gmail.com> writes:
Frank Benoit wrote:

 What I really miss, is a D indent tool that really works. I spent some
 time on the dparser and even had some success with indenting code, but I
 didn't continue.


Uncrustify supports the D language.

You may want to check it out.
http://uncrustify.sourceforge.net/

Ben
Aug 12 2006
parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Ben Gardner wrote:


 Frank Benoit wrote:

 What I really miss, is a D indent tool that really works. I spent some
 time on the dparser and even had some success with indenting code, but I
 didn't continue.


 
 Uncrustify supports the D language.
 
 You may want to check it out.
 http://uncrustify.sourceforge.net/


Oh. Thanks for the link. :)


P.S.
/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."

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.
Aug 13 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dawid Ciezarkiewicz" <dawid.ciezarkiewicz gmail.com> wrote in message 
news:ebmvsa$2up9$1 digitaldaemon.com...


 Even phobos sources have mixed space/tabs indentation (mixed in single
 file!) ... sad.


That's just Walter's coding "style."  It's not just phobos; it's everything 
he writes.  Including the DMD source.  Oh man.

I love hard tabs, and I don't mind spaces; but everything only falls apart 
when you mix them.  Like Walter.  :)
Aug 13 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:

 "Dawid Ciezarkiewicz" <dawid.ciezarkiewicz gmail.com> wrote in message 
 news:ebmvsa$2up9$1 digitaldaemon.com...
 

 Even phobos sources have mixed space/tabs indentation (mixed in single
 file!) ... sad.


 
 That's just Walter's coding "style."  It's not just phobos; it's everything 
 he writes.  Including the DMD source.  Oh man.
 
 I love hard tabs, and I don't mind spaces; but everything only falls apart 
 when you mix them.  Like Walter.  :) 


It works just fine when you set tabs to be 8 characters, as god intended 
them to be.
Aug 13 2006
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.
Aug 13 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Aug 14 2006
next sibling parent reply Derek Parnell <derek psyc.ward> writes:
On Mon, 14 Aug 2006 02:47:52 -0700, Walter Bright wrote:


 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.


LOL ... you *so* locked into the past its almost sad.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Mon, 14 Aug 2006 02:47:52 -0700, Walter Bright wrote:

 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.


 
 LOL ... you *so* locked into the past its almost sad.


I run the latest operating systems, have a modern HP laserprinter, etc. 
And what do they do? 8 column tabs. Do you know that the latest HTML 
browsers default to 8 column tabs for <pre> sections? I run the latest 
Thunderbird email system, and what does it do for text? 8 column tabs.

Using any other setting is like declaring that your inches are really 
1.82 centimeters long.
Aug 14 2006
parent reply Derek Parnell <derek psyc.ward> writes:
On Mon, 14 Aug 2006 10:19:32 -0700, Walter Bright wrote:


 Derek Parnell wrote:

 On Mon, 14 Aug 2006 02:47:52 -0700, Walter Bright wrote:

 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.


 
 LOL ... you *so* locked into the past its almost sad.


 
 I run the latest operating systems, have a modern HP laserprinter, etc. 
 And what do they do? 8 column tabs. Do you know that the latest HTML 
 browsers default to 8 column tabs for <pre> sections? I run the latest 
 Thunderbird email system, and what does it do for text? 8 column tabs.
 
 Using any other setting is like declaring that your inches are really 
 1.82 centimeters long.


Firstly, I didn't say you were the *only* luddite ;-) 

Secondly, I too use such equipment and software and I don't have any issue
with using hard-tabs, because I don't use tabs.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 Secondly, I too use such equipment and software and I don't have any issue
 with using hard-tabs, because I don't use tabs.


That is a workable solution, but I like using tabs. They make me more 
productive at the keyboard.

The real problem is the folks who set their *hard* tab stops at 
something other than 8. This is just a mistake. There's no problem in a 
decent editor to set the *soft* tab stops to 3, or whatever. Just not 
the hard ones.
Aug 14 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
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. :)
Aug 14 2006
parent kris <foo bar.com> writes:
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"
Aug 14 2006
prev sibling next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 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.


Out of the infinite number of ways an editor can display a tab on the 
screen or print it, it isn't screwed up in *only* one way. So, I'd say 
that the average probability of it being screwed up is 100%.
Aug 14 2006
prev sibling next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:

 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.


Might I suggest it also isn't screwed up if you're consistent in using 
either X spaces or one tab consistently to represent a level of 
indentation? :) (At least, that takes one possible way of screwing it up 
out of the equation)

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).
Aug 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Aug 14 2006
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright 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.


I don't see how using a consistent coding for indentation takes up any 
more screen space. Note though: I said "if you prefer 8-space 
indentation", which might have been a wrong assumption. I haven't 
checked in Phobos.
If you're using 8-space hard tabs + spaces to represent 4 spaces per 
indentation level or something like that then you're just being silly.

Just don't mix tabs and spaces for indentation. That's the most 
important thing.
Aug 14 2006
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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.



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?!?

hard tabs.



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).



Regan
Aug 14 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
 

 
 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.



 of hard tabs.
 



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).
 



Not really, because I follow that rule, and if tabs are set to 3 it gets 
all screwed up.
Aug 14 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Regan Heath wrote:

 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.


Only by default.  The first thing I do when configuring an editor is 
change the tab width to 4.  8 chars is simply too wide IMO, even for 
paragraph indentation.



 of hard tabs.




 
 Send it to where? The disk file? Then there aren't tabs in it anymore.


Right.  But is that a problem?  I'll admit it's a tiny time-saver to be 
able to move through tab-filled regions with the cursor, but it's just 
as easy (and even faster) to jump between words with control keys.

But all this is really a matter of opinion... which I guess is the 
point?  I've always favored using spaces because it preserves 
readability regardless of one's opinion of what the correct tab width is.


Sean
Aug 14 2006
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.



 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.
 


 of hard tabs.




 
 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).




 
 Not really, because I follow that rule, and if tabs are set to 3 it gets 
 all screwed up.
Aug 14 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Regan Heath wrote:

 
 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).


What about:

     int x,
         y,
         z;

     if( x == y ||
         y == z )
     {
         func( x,
               y,
               z );
     }

Changing tab widths can totally mess up this sort of thing if tabs were 
involved in the creation of any of the involved lines.  Things get even 
worse if some lines were indented with spaces and others with tabs. 
I'll admit that none if this is a problem for solo projects, but in a 
group it can be a disaster.  And maybe you can enforce indenting rules 
to this level of detail, but I can't :-)


Sean
Aug 14 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 14 Aug 2006 18:23:27 -0700, Sean Kelly <sean f4.ca> wrote:

 Regan Heath wrote:

  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).


 What about:

      int x,
          y,
          z;

      if( x == y ||
          y == z )
      {
          func( x,
                y,
                z );
      }


No problem. The above is formatted like so:

<t>int<s>x,<cr>
<t><s><s><s><s>y,<cr>
<t><s><s><s><s>z;<cr>
<cr>
<t>if(<s>x<s>==<s>y<s>||<cr>
<t><s><s><s><s>y<s>==<s>z<s>)
..etc..

you get the idea. where: <t> = tab, <s> = space

The rule "hard tabs first, spaces following" implies you cannot mix tabs  
and spaces, meaning, your line starts with tabs (denoting the left hand  
margin) then has characters or spaces but never another tab, therefore  
<t><s><t> or <s><t><s> is illegal.

In short, use tabs to indent the left hand margin only, and spaces for  
everything else.


 Changing tab widths can totally mess up this sort of thing if tabs were  
 involved in the creation of any of the involved lines. Things get even  
 worse if some lines were indented with spaces and others with tabs. I'll  
 admit that none if this is a problem for solo projects, but in a group  
 it can be a disaster.  And maybe you can enforce indenting rules to this  
 level of detail, but I can't :-)


I'll agree, trying to get a bunch of people to actually use the same  
formatting, or even to format their code consistently is nearly  
impossible..  in my ideal world I would have an editor which  
auto-formatted code that I was reading (regardless of the on-disk,  
in-file, actual format..) now that would be nice.

Regan
Aug 15 2006
parent Sean Kelly <sean f4.ca> writes:
Regan Heath wrote:

 On Mon, 14 Aug 2006 18:23:27 -0700, Sean Kelly <sean f4.ca> wrote:

 Regan Heath wrote:

  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).


 What about:

      int x,
          y,
          z;

      if( x == y ||
          y == z )
      {
          func( x,
                y,
                z );
      }


 
 No problem. The above is formatted like so:
 
 <t>int<s>x,<cr>
 <t><s><s><s><s>y,<cr>
 <t><s><s><s><s>z;<cr>
 <cr>
 <t>if(<s>x<s>==<s>y<s>||<cr>
 <t><s><s><s><s>y<s>==<s>z<s>)
 ..etc..
 
 you get the idea. where: <t> = tab, <s> = space
 
 The rule "hard tabs first, spaces following" implies you cannot mix tabs 
 and spaces, meaning, your line starts with tabs (denoting the left hand 
 margin) then has characters or spaces but never another tab, therefore 
 <t><s><t> or <s><t><s> is illegal.


Oh I see, you place the restriction at the column level.  That would 
work, though it would mean holding down my spacebar a lot :-)


 I'll agree, trying to get a bunch of people to actually use the same 
 formatting, or even to format their code consistently is nearly 
 impossible..  in my ideal world I would have an editor which 
 auto-formatted code that I was reading (regardless of the on-disk, 
 in-file, actual format..) now that would be nice.


I bet emacs could be made to do this with some work, though it would 
save files in the same formatting.


Sean
Aug 15 2006
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.
Aug 14 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
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.


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... :)

/Oskar
Aug 14 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Oskar Linde wrote:

 Today, the benefits are not as clear... :)


It finds all the bugs in your text processing code where you forgot to 
include \t in your whitespace checking!
Aug 14 2006
parent Derek Parnell <derek psyc.ward> writes:
On Mon, 14 Aug 2006 10:22:29 -0700, Walter Bright wrote:


 Oskar Linde wrote:

 Today, the benefits are not as clear... :)


 
 It finds all the bugs in your text processing code where you forgot to 
 include \t in your whitespace checking!


isspace()?

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 14 2006
prev sibling parent reply Derek Parnell <derek psyc.ward> writes:
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.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 14 2006
parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 14 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
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
Aug 14 2006
parent Sean Kelly <sean f4.ca> writes:
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
Aug 14 2006
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
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. ;)

-- 
- EricAnderton at yahoo
Aug 14 2006
next sibling parent reply kris <foo bar.com> writes:
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
Aug 14 2006
parent reply pragma <ericanderton yahoo.com> writes:
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
Aug 14 2006
next sibling parent James Dunne <james.jdunne gmail.com> writes:
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
Aug 14 2006
prev sibling parent reply kris <foo bar.com> writes:
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!
Aug 14 2006
parent reply kris <foo bar.com> writes:
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;inden
}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!
Aug 15 2006
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 15 Aug 2006 00:06:37 -0700, kris wrote:



 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!


This is why I thank Bob I'm an Aussie. ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
15/08/2006 5:32:58 PM
Aug 15 2006
prev sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
kris wrote:

 
 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__*__1
3(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!


ROFL.

Congrats.  I think you just posted the best example of "death by 
specification" anyone could have conjured.  As you know, we need that 
kind of humor* around here (at work I mean).

(* or "humour", if you're into that sort of thing)

-- 
- EricAnderton at yahoo
Aug 15 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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. ;)
 


I'm strangely anal about my code being at least somewhat aesthetic to the
eyes... a random 
habit I suppose I picked up from my original C++ teacher a decade ago.  It does
help me 
when reading code, though, so I stick to using spaces whenever possible. 
(Thank goodness 
for EditPlus's "insert tabs as spaces" setting, and for the Ctl+Arrow behavior
of Windows 
cursors.)

-- Chris Nicholson-Sauls
Aug 14 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ebp2j7$1o5c$1 digitaldaemon.com...


 It works just fine when you set tabs to be 8 characters, as god intended 
 them to be.


Or, you could just set them to 4 characters, and always use tabs.  Then 
everyone would be able to control the indentation as much as they want. 
That's the whole point of using hard tabs in a modern editor.
Aug 14 2006
parent reply Sean Kelly <sean f4.ca> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ebp2j7$1o5c$1 digitaldaemon.com...
 

 It works just fine when you set tabs to be 8 characters, as god intended 
 them to be.


 
 Or, you could just set them to 4 characters, and always use tabs.  Then 
 everyone would be able to control the indentation as much as they want. 
 That's the whole point of using hard tabs in a modern editor. 


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. 
  I've worked on projects like this (including the one I'm on now) and 
the tabs are a disaster.  Given the relative ease with which modern 
editors can jump from word to word and eat whitespace, I simply don't 
understand the attachment to hard tabs.


Sean
Aug 14 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:ebq7gr$2ski$1 digitaldaemon.com...


 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.


Oh I never, ever use tabs in internal indentation for that very reason. 
Then again, I rarely internally indent my code.


 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. I've worked 
 on projects like this (including the one I'm on now) and the tabs are a 
 disaster.


Sounds like a reason to have a group coding style.


 Given the relative ease with which modern editors can jump from word to 
 word and eat whitespace, I simply don't understand the attachment to hard 
 tabs.


I don't like being able to select the individual spaces in the indentation, 
or being able to accidentally get the indentation off by a space or two 
through odd editing.  And not all editors are created equal in the cursoring 
respect - some can go thru spaces as if they were tabs; some depend on 
global settings to determine if that happens; and some don't offer it at 
all.  With tabs, there's no other way to cursor through them.
Aug 14 2006
prev sibling next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Kelly wrote:

 Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ebp2j7$1o5c$1 digitaldaemon.com...


 It works just fine when you set tabs to be 8 characters, as god 
 intended them to be.


 Or, you could just set them to 4 characters, and always use tabs.  
 Then everyone would be able to control the indentation as much as they 
 want. That's the whole point of using hard tabs in a modern editor. 


 
 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. 
  I've worked on projects like this (including the one I'm on now) and 
 the tabs are a disaster.  Given the relative ease with which modern 
 editors can jump from word to word and eat whitespace, I simply don't 
 understand the attachment to hard tabs.
 
 
 Sean


I'm not too keen on using tabs in inner indentation, for reasons like 
that. But for start-of-line indentation, hards tabs is the way to go. 
(with a width choice of 4 characters)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 14 2006
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 14 Aug 2006 09:14:04 -0700, Sean Kelly <sean f4.ca> wrote:

 Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message  
 news:ebp2j7$1o5c$1 digitaldaemon.com...


 It works just fine when you set tabs to be 8 characters, as god  
 intended them to be.


  Or, you could just set them to 4 characters, and always use tabs.   
 Then everyone would be able to control the indentation as much as they  
 want. That's the whole point of using hard tabs in a modern editor.


 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.


   I've worked on projects like this (including the one I'm on now) and  
 the tabs are a disaster.  Given the relative ease with which modern  
 editors can jump from word to word and eat whitespace, I simply don't  
 understand the attachment to hard tabs.


The attraction is the flexibility to view the code with your preferred  
indentation width/size. It's like defining your constant values at the top  
of your source, eg.

const int TAB_WIDTH = 4;

and using that integer in the code, instead of using the literal value '4'.

Regan
Aug 14 2006
parent Sean Kelly <sean f4.ca> writes:
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
Aug 14 2006
prev sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
Aug 14 2006
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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.
Aug 14 2006
parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Anders F Björklund wrote:


 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.


You'd always had a choice of using (or not) language that enforces some
coding style.


 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.


Neither I do.
Aug 15 2006
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Dawid Ciężarkiewicz wrote:


I like choice.


 
 You'd always had a choice of using (or not) language that enforces some
 coding style.


Right, which is why I don't use Python if I can somehow avoid it...

--anders
Aug 15 2006