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

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.

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!

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.

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

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.

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

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

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

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