[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Karthik Kumar V wrote:
Hi,
Is there much ado about this subject or what? I don't see any reason why
it can be expected that everybody is comfortable with a common style of coding.
So why not make it easier, by applying indent, with profiles? Whomsoever
chooses the style he/she is most convenient with, can customize the
source to their preferences.
BTW It makes sense to keep tabs for most indenting, than spaces. This is
because, the tab sizes can be specified later, and converted into spaces, later,
according to what people prefer. I'm sure many people may not agree with
me, but I feel that it makes things easier while coverting it later to
spaces. (Even sed can do the conversion part!!)
That's about it. :)
Regards,
I usually don't like tabs, because you can't pick what size you want to
view them at. Take the case of continutation indent, where the author's
tab size is 8:
T------>myLongFunctionCall( parameter1, parameter2, parameter3,
T------>T------>T------> parameter4, parameter5, parameter6 );
Now on my machine, let's say I set tabsize to 2:
T>myLongFunctionCall( parameter1, parameter2, parameter3,
T>T>T> parameter4, parameter5, parameter6 );
The parameters don't line up any longer. When using spaces, you are
guaranteed the code is viewed as intended, no matter what the editor's
settings. There are some other cases like the above where the tab
method breaks down.
What's worse with tabs is that since the tab size is fixed, you have to
use a mix of tabs and spaces. You'll have multiple people who will
replace tabs with spaces, and it looks right on their machine, so they
think it is all right.
T-->T-->someFunc();
T--> otherFunc();
yetAnotherFunc();
And when viewed on my machine with tab size 2, I see
T>T>someFunc();
T> otherFunc();
yetAnotherFunc();
And believe it or not I see this case constantly, in horrible cases
involving nested loops and braces where one person added a line with spaces.
So you are forced to have every person on the project use the same tab
size, defeating the point of tabs.
Of course, saying you are supposed to use spaces has the same problem,
except that it is usually less prone to set the editor to use only
spaces (replacing tabs w/spaces) rather than set the tab size and some
people mix tabs and spaces. And you know it will work for viewing in
all other editors w/o configuration.
However on my current project at work, everyone seems dead-set on tabs,
and I allowed it only because our editor supports "smart tabs" which
gets rid of the continuation indent problem (much more common in Java
than C). What it does is use tabs up to the indentation point, then
spaces thereafter:
T------>myLongFunctionCall( parameter1, parameter2, parameter3,
T------> parameter4, parameter5, parameter6 );
This way I can set my tab size to whatever I want and it is viewed
properly. The only problem is that still some team members refuse to
use the auto-indenting features of the editor and still mix tabs/spaces
or put tabs in the continuation indent, however rerunning the
auto-indenting feature in our editor is easy.
No way is perfect, mostly because people refuse to follow standards or
are just too lazy to care. But I choose the smart tabs method, because
if implemented by everyone, it has the benefit of choosing indent size
with tabs and the space reduction, but the formatting capability of spaces.
Jason