Interesting language comparison article [OT]

Oskar Linde oskar.lindeREM at OVEgmail.com
Wed Mar 15 01:13:42 PST 2006


Jarrett Billingsley skrev:
> "Hasan Aljudy" <hasan.aljudy at gmail.com> wrote in message 
> news:dv84il$1q3l$1 at digitaldaemon.com...
>> Stick to the tab key all you want. I want to kill the ascii code for the 
>> "so called" tab character!!
> 
> I never understood this whole hard-tab-hating stuff.  Everything lines up on 
> nice neat columns, they can be set to whatever width you want, and it's much 
> quicker to move through them using the arrow keys.  What's so great about 
> spaces? 

I think Emacs is to blame for many of the problems with hard tabs. Emacs 
doesn't use tabs for indentation. It uses spaces. Tabs are used to 
optimize the number of spaces needed. The problem with this is that the 
tab width isn't standardized. (8 used to be more or less the standard, 
but not anymore)

This has some implications. If you use emacs with 3 character 
indentation, (and the default 8 character tab width) you get: (. is 
space, - is tabbed space)

...if (1) {
......if (1) {
--------.if (1) {
--------....if (1) {
--------.......if (1) {
----------------..if (1) {

etc...

(The Phobos and DMD front end sources are an example of using 4 
character indentation and width 8 tabs:

....for (i = 0; i < global.params.objfiles->dim; i++)
....{
--------if (i)
--------....cmdbuf.writeByte('+');

Even when you use the same tab width as indentation width, you get 
problems when lining up lists, like:

void myfunc(int firstArgument,
--------....int secondArgument,
--------....int thirdArgument)

IMO, the best strategy would be to use tabs for indentation and spaces 
for alignment. That way, the code would look good at any tab-size 
setting (adjustable by user preference) and arguments would still line 
up properly.

/Oskar



More information about the Digitalmars-d mailing list