A stylistic question.

[Andrew Poelstra]

CBFalconer wrote:
James Dow Allen wrote:

In such a trivial case we can agree to quibble, or, better yet,
disdain. But suppose one is doing a 3-D convolution:

for (x = 0; x < Wid; x++)
for (y = 0; y < Hei; y++)
for (z = 0; z < Dep; z++) {
valu = 0;
for (xx = 0; xx < Filt->wid; xx++)
for (yy = 0; yy < Filt->hei; yy++)
for (zz = 0; zz < Filt->dep; zz++) {
valu += Isig[x+xx+Xoff][y+yy+Yoff][z+zz+Zoff]
* Filt->kern[xx][yy][zz];
}
Osig[x][y][z] = valu;
}

Anyone who will claim that this loop becomes "more readable" when four
more levels of indentation are added has probably been over-indulging
in ... (well, in another newsgroup, someone has taken to rhyming James
with Flames and blames so let's avoid further charges of hyperbole).

Well, you could indent by less than 8 spaces:

for (x = 0; x < Wid; x++)
for (y = 0; y < Hei; y++)
for (z = 0; z < Dep; z++)
{
valu = 0;
for (xx = 0; xx < Filt->wid; xx++)
for (yy = 0; yy < Filt->hei; yy++)
for (zz = 0; zz < Filt->dep; zz++)
{
valu += Isig[x+xx+Xoff][y+yy+Yoff][z+zz+Zoff]
* Filt->kern[xx][yy][zz];
}

Osig[x][y][z] = valu;
}

Now my deepest indentation is less than yours, with full indenting.
And it was /far/ easier to figure out what loop what is in.

I disagree that it's easier. I actually very much like the
non-indented
nested loop style.

This is going to change the subject a bit, but still talking about
style, so I'll leave it in this thread. I've never found an
indentation
scheme for line continuations that I like. What do you think
about this:

#define ____ /* to denote a continued line*/

if (really_long_name -> a &&
____ (b == 8) && (c & 0x08) ||
____ (another_boolean_condition) &&
____ (yet_another() == 2) ) {
do _stuff()
}

I want something at the start of the line with the
same level of indentation as the "if". "..." would
be better than underscores, but "..." would clash
with variadic function decldarations, and "...." isn't
a valid name for a macro.

At the moment I think using ____ is a pretty poor
idea, but I'd really like to hear suggestions on
better ways to do continuations. I've thought about
column-aligning '\' at the end of the lines way out
to the right, but it's not as much of a visual cue
as I'd like. half or double indenting the continued
line just doesn't work as well as it ought.

I align the continued line to the right side of the expression:
int x = 2 + 5 \
+ 6 / 2;

That looks terrible only because it is so artificial.

 

[Andrew Poelstra]

I align the continued line to the right side of the expression:
int x = 2 + 5 \
+ 6 / 2;

That looks terrible only because it is so artificial.

Oops. I quoted /way/ too much. These stupid slow
school computers take 2 seconds to delete an single line.

 

[ais523]

#define ____ /* to denote a continued line*/

At the moment I think using ____ is a pretty poor
idea, but I'd really like to hear suggestions on
better ways to do continuations. I've thought about
column-aligning '\' at the end of the lines way out
to the right, but it's not as much of a visual cue
as I'd like. half or double indenting the continued
line just doesn't work as well as it ought.

____ is in implementation namespace, because it starts with two
underscores, and therefore dangerous to use as a macro name.
Personally, I tend to indent the continued line to the point where the
bracketed expression containing it started, e.g.

my_array[my_function(6)] = another_function(45 + i*6 +
st2[7]);

 

[Robert Latest]

On 18 May 2006 09:44:43 -0700,

This is going to change the subject a bit, but still talking about
style, so I'll leave it in this thread. I've never found an
indentation
scheme for line continuations that I like. What do you think
about this:

[...]

I always do it like this:

if (really_long_name -> a &&
(b == 8) && (c & 0x08) ||
(another_boolean_condition) &&
(yet_another() == 2) ) {
do _stuff()
}

My "normal indent" is 4 spaces, but for continuations within if, for, or
while staements I use 8 and go back to 4 for the actual block.

For long funtion argument lists, I indent 4 spaces:

fprintf(stderr,
"...really long format string. In fact so long that the"
" string itself doesn't fit on a line",
foo, bar, baz,
and, many, more, args);

robert

 

[pete]

On 18 May 2006 09:44:43 -0700,

This is going to change the subject a bit, but still talking about
style, so I'll leave it in this thread. I've never found an
indentation
scheme for line continuations that I like. What do you think
about this:

[...]

I always do it like this:

if (really_long_name -> a &&
(b == 8) && (c & 0x08) ||
(another_boolean_condition) &&
(yet_another() == 2) ) {
do _stuff()
}

I prefer to start the broken lines with a binary operator,
if possible,
and to move the opening brace back to the "if" column.

if (really_long_name -> a
&& (b == 8) && (c & 0x08)
|| (another_boolean_condition)
&& (yet_another() == 2))
{
do _stuff()
}

Indian Hill
http://www.psgd.org/paul/docs/cstyle/cstyle06.htm

 

[James Dow Allen]

On 18 May 2006 09:44:43 -0700,

I always do it like this:

if (really_long_name -> a &&
(b == 8) && (c & 0x08) ||
(another_boolean_condition) &&
(yet_another() == 2) ) {
do _stuff()
}

I also do it that way: double-tab for the continuation.
Given my track record for other's liking my style, I hope
Robert doesn't decide to switch to something else now.

My "normal indent" is 4 spaces, ...

My "normal indent" is one TAB character, and I'm amazed people
mess around with spaces. It seems futile to try a TAB other than
8 spaces, though I admit 6 spaces would be slightly better.
4 spaces of indentation is almost too little for my taste.
I *do* like being able to line up begins and ends easily, so if I was
ever forced to work on code that used (gasp!) 2-space indentation
I'd become an indent(1) fan *real* quick. (2-space indentation may
look
OK on little fragments, but am I the only one that ever puts more than
3 or 4 lines of code into the body of a for or if?)

James Dow Allen

 

[Bill Pursell]

I also do it that way: double-tab for the continuation.
Given my track record for other's liking my style, I hope
Robert doesn't decide to switch to something else now.


My "normal indent" is one TAB character, and I'm amazed people
mess around with spaces. It seems futile to try a TAB other than
8 spaces, ...

<snip>

That's actually the motivation behind my looking for a new
continuation style. I've also used double indent for
continuations, but I've recently changed from being a
tabstop=4 person to being a tabstop=8, and 16 spaces
is too much for the line continuation. I don't want to
go to half-indents, because I'm trying to go back to
the tab-only indent style (I'm tired of using spaces
just to conform to the wishes of people
who don't know how to use an editor.)

It'd be cool if you could do:

if (this_is_the_first_line == 5 && \
\ this_is_the_continuation == 4)

and use the '\' to mark continuations both at the
end of the line and at the begninning.

 

[pete]

(I'm tired of using spaces
just to conform to the wishes of people
who don't know how to use an editor.)

That's a good way to avoid the problem
of your code being *too* easy to read,
if you're really capable of considering that to be a problem.

 

[Bill Pursell]

That's a good way to avoid the problem
of your code being *too* easy to read,
if you're really capable of considering that to be a problem.

The only problem that occurs when you use tabs
for indentation is when someone else comes along
and edits the code using spaces. From my perspective,
once someone edits the code, the readability issue
and any problems that may occur are their own
responsibility. In other words, my code is very
readable--does anyone not think that about their
own code? Readability problems that may occur
in edited versions that are descended from
my code are the responsibility of the person who
made the changes.

Is using tabs for indentation a decision I'll regret? Ask
me in 12 months.

 

[Andrew Poelstra]

I *do* like being able to line up begins and ends easily, so if I was
ever forced to work on code that used (gasp!) 2-space indentation
I'd become an indent(1) fan *real* quick. (2-space indentation may
look
OK on little fragments, but am I the only one that ever puts more than
3 or 4 lines of code into the body of a for or if?)

Am I the only one who ever nests blocks more than two levels deep?
Suppose I had a function that implemented Warshall's algorithm for
finding the transitive closure of a matrix. It's a function with
three loops nested inside of it.

Running anything inside of the third loop would take 8 spaces with
2-space indentation, while it would take 32 spaces with your tabbing
strategy (not to mention the fact that will these new GUI's people
are using, tab may or may not switch you from your editor window).

On a 80-character wide screen, I'd be taking up 32 spaces, which
is /40%/ of my line, with nothing but whitespace! Somehow 10% seems
more attractive.

 

[Richard Heathfield]

James Dow Allen said:

I *do* like being able to line up begins and ends easily, so if I was
ever forced to work on code that used (gasp!) 2-space indentation
I'd become an indent(1) fan *real* quick. (2-space indentation may
look
OK on little fragments, but am I the only one that ever puts more than
3 or 4 lines of code into the body of a for or if?)

I use two-space indent, and I have found that it works very well. History: I
used to use tabs (with 8-stops), but that got silly fast, and I converted
to 4-stops (but still tabs). But then I got into Usenet. Tabs being frowned
upon, I got into the 2-space indent habit for Usenet posts (because it was
so much quicker!), and found that I liked it so much I adopted it for
non-Usenet code too.

I have no problem matching braces (because I lay them out Allman-style, so
it's very obvious) - and anyway, vim can jump between { and } with a single
keystroke, so even if it weren't obvious it wouldn't matter that much.

But yes, you're right - indent(1) is our friend.

 

[Chris Hills]

Is using tabs for indentation a decision I'll regret? Ask
me in 12 months.

You will.

Why not set the editor to replace tabs with spaces?

 

[pete]

Bill


You will.

Why not set the editor to replace tabs with spaces?

That's what *I* did.
It's more obviously the right way to go,
if you post a lot of code to Usenet.

 

[Keith Thompson]

My "normal indent" is one TAB character, and I'm amazed people
mess around with spaces. It seems futile to try a TAB other than
8 spaces, though I admit 6 spaces would be slightly better.
4 spaces of indentation is almost too little for my taste.
I *do* like being able to line up begins and ends easily, so if I was
ever forced to work on code that used (gasp!) 2-space indentation
I'd become an indent(1) fan *real* quick. (2-space indentation may
look
OK on little fragments, but am I the only one that ever puts more than
3 or 4 lines of code into the body of a for or if?)

It's important to distinguish between tabstops and indentation levels.
Too many people seem to think they have to be the same thing.

Tabstops, in my opinion, should be set at 8 columns, always. That's
the default setting on every system I've used. Setting it to
something other than 8 means that anything containing tabs will look
different in *some* context (printing, viewing with a different
editor, etc.).

My own preferred indentation level has changed over the years;
currently, I like 4 spaces. My preferred text editor, vi, has
separate settings for "tabstop" and "shiftwidth". I type ^T at the
beginning of a line to indent by one shiftwidth, and ^D to un-indent
by one shiftwidth. vi automatically converts indentation to a
sequence of tabs and spaces (for example, a 12-column indent becomes a
tab followed by four spaces); it's a feature I wish I could turn off,
but I live with it. (I think some versions of vi can turn this off;
nvi can't.) I've defined an editor macro that filters the buffer
through "expand", which expands all tabs to the right number of
spaces.

I have no doubt that emacs can do something similar.

For the most part, I don't "mess around with spaces"; I let my editor
take care of it for me. Computers are generally pretty good at that
kind of thing.

 

[Bill Pursell]

You will.

Why not set the editor to replace tabs with spaces?

Aesthetics. And being able to do a single backspace
to lower the indentation level. (It's easier than ^d).

About 2 years ago, I decided to not use tabs at all, except
in makefiles. A few weeks ago, I decided that 4 spaces for
indentation wasn't enough, and I wanted 8. Had I been
using tabs, I could now set my tabstop to 8, and all would
be well. Instead, every time I open a file, I have to filter
it to change the indentation. That's not a big deal, but
it's annoying. One of my thoughts is that since
I'm using a tabstop of 8, I'm far less likely to have any
problem with the tab/space issue. (Of course, that
may eliminate the point of using tabs, since I want the
flexibility of being able to change the tabstop.)

Everyone wants stable coding standards in a project,
but the reality is that it doesn't happen. I'm constantly
looking at code that is totally unreadable and that I have
to run through indent before I can even stand to look
at it. Maybe by imposing the rule that code be indented
with tabs and rejecting code that fails to conform will
help, maybe it won't. If I'm unable to enforce that rule,
I'm no worse off than I am now, and I'll have to filter
the code. But maybe I can catch those damn 2 space
indenters who use a tab for the 4th level of indentation...
those people are evil...

 

[Ben Pfaff]

About 2 years ago, I decided to not use tabs at all, except
in makefiles. A few weeks ago, I decided that 4 spaces for
indentation wasn't enough, and I wanted 8. Had I been
using tabs, I could now set my tabstop to 8, and all would
be well.

Really? Do you not line up continuation lines after parentheses?
long_function_name (long_function_argument_1,
long_function_argument_2,
long_function_argument_3,
long_function_argument_4);

 

[Sjouke Burry]

Really? Do you not line up continuation lines after parentheses?
long_function_name (long_function_argument_1,
long_function_argument_2,
long_function_argument_3,
long_function_argument_4);

I do, and get something like thisi hope the tabs show)
long_function_name ( long_function_argument_1,
long_function_argument_2,
long_function_argument_3,
long_function_argument_4);
I like tabs, and i hate it when people(or editors)
start to change it to spaces,especially when they
return the code to me

 

[Tomás]

James Dow Allen posted:

My "normal indent" is one TAB character, and I'm amazed people
mess around with spaces.

Two things I do:

1) Write my programs in a fixed-width font (Courier New), and in plain
black text.

2) Hit the space bar four times when I want to indent.


Why?

Because if I become accustomed to fancy colours, and fancy automatic
indentation features, then I'll be lost if I'm ever found without them.
This happened to me in the past. When I first started reading code on
newsgroups, I simply couldn't read it because I was lost without syntax
highlighting and different colours for keywords, etc. So I decided to wean
myself off fancy features so that I could program with the bare
necessities.

Give me notepad with Courier New and I'm good to go.


-Tomás

 

[Ian Collins]

James Dow Allen posted:





Two things I do:

1) Write my programs in a fixed-width font (Courier New), and in plain
black text.

2) Hit the space bar four times when I want to indent.


Why?

Because if I become accustomed to fancy colours, and fancy automatic
indentation features, then I'll be lost if I'm ever found without them.
This happened to me in the past. When I first started reading code on
newsgroups, I simply couldn't read it because I was lost without syntax
highlighting and different colours for keywords, etc. So I decided to wean
myself off fancy features so that I could program with the bare
necessities.

Give me notepad with Courier New and I'm good to go.

What do you do when you refactor a bit of code and extract some indented
code into a function?

I don't know how this could be done easily without some form of auto indent.

 

[Ben Pfaff]

I do, and get something like thisi hope the tabs show)
long_function_name ( long_function_argument_1,
long_function_argument_2,
long_function_argument_3,
long_function_argument_4);

Changing the tab width will still break the alignment of the
function arguments.