Why?? (prog question)

[Polytropon]

On Tue, 31 Mar 2009 18:53:51 -0400, William Gordon Rutherdale <will.rutherdale at utoronto.ca> wrote:
> Are you serious? 

Serious question, yes.



> You set the standard on a given project.  You decide
> whether you are using spaces or tabs.  If spaces, you decide how many
> spaces per indent level.  You ask the programmers to submit code in that
> format.  It doesn't jump around randomly from one line to the next.

Okay, now I understand what you mean. "Consistency" refers to
the usage of spacing / tabbing for a given project that is
adopted by several programmers. Yes, I agree with that: It's
a very bad idea to have many different styles within the same
project.



> You are trying to make it sound like a big problem, but it isn't.

When I need to read / work with other's code, it's can develop
into problems. Natural habits like hitting the tab key are
very hard to change several times, for each project a different
rule.



> Just my view based on years of experience.  Don't take it too seriously.

Okay, understood. "Better" often depends on what one is used
to, except it can be put into a standpoint-independent discussion
of pros and cons.



> > When I would compare both indentation forms, I'd say that tabbing
> > is the better form because
> >  + you can set your individually preferred tab with using the
> >    settings of your editor, be it 1, 4 or 8,
> >   
> Why is this flexibility important?  The more important thing is to have
> consistently indented code.  There is no great benefit in letting
> different programmers see the code indented to different levels.  They
> just want to be able to read it.

But the ability to read it is not the only important thing. It's
how you use it, because programmers usually do more than just
reading, they continue developing. The tab approach allows them
to have their individual viewing options without needing to
reformat the code. While programmer A likes ^TD2, another might
want to work with ^TD8 or even ^TD10. The code stays the same.



> >  + you can change the indentation while you're coding, e. g. when
> >    the indentation level makes the code exceed the right margin
> >    of your editor's window,
> So what?  How many times have you actually done this in the past year? 
> Be honest.

I belong to the ones who like ^TD8. The ability of changing the
indentation width wasn't meant to be an agrument *for me*, but
*for me and others*. It's not that I change the width very often,
and as I think you've already guessed, I don't do it on a regular
basis. But maybe if I pass ^TD8 code to you, you would want to
work with it in ^TD4. THIS is the ability of changing I wanted
to refer to.



> >  + you need more keypressing to get through the indentation with
> >    the spaces, one keypress per space, while you only need one
> >    keypress per tab (which equals one indentation level),
> >   
> Not true.  You set up your editor settings to automatically do this for
> you.  Most editors have this capability. 

Not all editors have this ability. And especially under low level
circumstances, e. g. editing with vi in SUM required in a maintenance
phase, you'll be happy about every keystroke you can save.



> On my editor (vim) it only
> takes at most one keypress to indent.  You still might use the tab key,
> or even have the editor automatically format for you based on syntax.
> Editors have done this for decades.  Your objection is specious.

I'd like to add that tab based indentation is independent from
the functionalities of a specific editor. It's even handy for
printing where the tab width can be set to a certain value.
Okay, your counterargument could now be: "Who prints today
anyway?" :-)

Not every programmer uses vim, emacs or Eclipse. Some really
like the "old fashioned" ways like joe. The tabbing approach
allows them not to take the indentation spaces as what they
are: space characters.



> >  + per indentation level only 1 byte is needed (tab = ASCII 9), while
> >    spacing requires more bytes, one per space (space = ASCII 32),
> >   
> Are you telling me that in an age when most cheap user workstations have
> hundreds of gigabytes of disk space, you need this kind of savings?
> This is a *very* weak point.

Maybe, but it *is* a point. :-)



> >  + while you can convert tabs into spaces, you cannot easily convert
> >    spaces back into tabs, and finally
> >   
> Not true.  It is extremely easy to convert both directions.  The unix
> 'expand' command converts one direction, and 'unexpand' goes the reverse
> direction.  These unix utilities have been around as long as 'cat' and 'ls'.

Thanks for this advice, these seem to be really handy tools. It's
worth mentioning that they will work only as ling as the "internal
guidelines" for spacing / tabbing are followed, or else only rubbish
will come out.



> Moreover the whole point is moot anyway.  There are lots of high quality
> code formatters available.  One called 'Artistic Style' is well known
> and very capable.  On a lot of projects these days, people get sick of
> these kinds of arguments and just run all the code they receive through
> a code formatter like astyle.  It lets you set all kinds of options such
> as brace placement, spacing between parameters, indentation method, and
> so on.  If asking people to change their editor settings doesn't work,
> this thing fixes it up.

On e you setup your reformatter correctly (as "according to the
corporate guidelines"), this is a valid solution, yes.



> >  + even FreeBSD uses the tabbing style.
> >
> >   
> And therefore if I submit code for FreeBSD then I will use that format.
> However I wouldn't recommend it for other projects where that decision
> has not been established.

According to your above argumentation, summarized as "it doesn't really
matter how you indent, or even if you indent", this is an acceptable
standpoint.

Personally, I have the (maybe outdated) opinion that a programmer should
not only care for his programs to be valid, correct, efficient, well
structured, intended and documented, but also tidy and styled. What's
to understand from these words can be very individual, I agree.



> There are lots of cases where it's hard to make code line up the way you
> want it with tabs.  Often code that looks good with one tab length
> setting (say 8) doesn't look so good with another (say 4).  It gets
> especially bad when there are a few space characters thrown in, which
> people often do.

Okay, I didn't think of this. Taking this argument into mind, spaces
can be useful for parameter lists that don't fit into one line, but
should line up after the opening (, e. g.

	foofunction(&data, "%d,%d,%d", doodle.x, doodle.y, doodle,z,
	            foo, bar, pups, furz, "This is some stupid text.",
	            doom[dee].quoggle);

This wouldn't be easy to achieve with tabs, especially when their
width may vary.


Thank you for your arguments, I stand partially corrected. :-)



-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...