On Tue, Sep 16, 2014 at 11:09:04AM +0200, Vincent Lefevre wrote: > On 2014-09-11 19:42:43 -0500, Derek Martin wrote: > > On Thu, Sep 11, 2014 at 10:12:43AM -0700, Gary Johnson wrote: > > > I think that's just a matter of taste and what your used to. > > I agree, but I just think that tab characters should never be used > for indenting. They can break alignment in diff output, and break > copy-paste under some conditions too.
In principle it doesn't matter, as long as they are used (or not used)
consistently. I used to favor tab for indent, space for alignment,
BUT...
In practice it's unworkable. Humans aren't meticulous enough to get
it right consistently, and you can't even get people to configure this
consistently in their editors, so your source code becomes a mess.
Pretty much guaranteed.
> With the GNU coding style, one generally has a 4-column indent,
> due to the "{" / "}" lines, which is enough (and sometimes too
You don't. The '{' lines count--they are not invisible. So you get a
bunch of blocks that look like someone is drawing mountain ranges,
instead of writing blocks. It also wastes lines, as I said.
for (i = 0; i < n; i++)
{
if (i == 2)
{
do_some_stuff();
do_other_stuff();
}
something_else();
}
blech();
Horrible. The braces are nothing but noise, and reduce the blockiness
of your blocks.
for (i = 0; i < n; i++){
if (i == 2){
do_some_stuff();
do_other_stuff();
}
something_else();
}
yay();
So much more concise (20% fewer lines), clearer, and the brackets line
up with the flow control statements which start their respective
blocks so you can find them at a glance. They also line up with other
statements at the same logical indent level, which they don't with
GNU. Much, much easier to visually parse.
It matters little in these trivial examples, but in longer blocks
with more complicated logic, it can matter very much. Especially if
someone updating the code makes a few mistakes here and there... it's
generally a lot easier to pick them out because they stand out more as
being out of place.
> much in case of many nested blocks). I've seen code with 8-column
> indenting, and this is completely unreadable in a 80-column
> terminal because most of the lines are too long.
This can happen, but I've often found it happens due to bad design.
Well structured code can avoid it most of the time... it's very often
a sign your functions are doing too much. I think 4 is a good
compromise, but 8 is better than 2. When it can't be avoided,
splitting the line and lining up your function arguments keeps it most
readable. You may also just have to try harder to keep element names
short but still descriptive.
> Now, perhaps editors should provide block coloring to distinguish
> them better (or side bars in different styles).
>
> > - makes it harder to distinguish conditionals from function calls,
> > both for the programmer, and for coding tools that try to care
>
> If you mean "if (...)" vs "foo(...)", I think it should be better
> done via coloring of *keywords*.
No, that's a giant fail.
int my_func(void);
[...]
int main(...)
{
int a = my_func();
...
}
Keyword coloring can not color my_func, EVER, because it is not a
keyword. Syntax coloring can. Some editors, like vim, can be told
that my_func is a function, and colorize it accordingly... however if
two different programmers use that name, and one uses it as a function
and the other uses it as data, you lose. If you stick to foo() as
function call and foo () as conditional, it always gets colorized
properly (at least in all of the currently most popular languages).
Sure, it dictates some elements of style, but it only serves to
eliminate BAD style. ;-) (Yes, that's somewhat tongue in cheek.)
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgp9CVZCz0YRW.pgp
Description: PGP signature
