A stylistic question.

[Mark Healey]

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

--
Mark Healey
marknews(at)healeyonline(dot)com

[Richard Heathfield]

Mark Healey said:

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?
Why not just write a function to do this?

Presumably stuff() changes each time, but you could pass a function pointer
in to do the actual work.

In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

This is kind of what functions are for.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Bill Pursell]

Mark Healey wrote:

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

If I were maintaining the code, I'd probably be okay with it, in the
sense that I would curse your name for only a few days. :) Richard
Heathfield's suggestion to make it a function is probably better, but
does bring up an optimization point. If stuff() doesn't change with
each call, then making it a function is no big deal since it will
probably wind up being inlined, but if stuff does change and you
pass a pointer to the appropriate function, I think your run-time
is going to suffer from that overhead. I've been plagued with
a similar concern for a while now:

suppose my inner-most loop contains a single function call to
a very small function. Based on a run-time parameter, the
function changes, but for any instantiation of the program
that function remains constant. I see 2 ways to code that:

method 1)
typedef void (*my_foo)(void);
void foo1(void) { return;}
void foo2(void) { return;}
void foo3(void) { return;}

int main(int argc, char **argv)
{
my_foo select[3] = {foo1, foo2, foo3};
my_foo f;

f = select[argc-1];

do {
f();
} while (1);
}
*********************************
method 2)
int main(int argc, char **argv)
{

switch(argc) {
case 1: do foo1(); while (1);
case 2: do foo2(); while (1);
case 3: do foo3(); while (1);
}
}
In terms of style, I prefer method 1, but I'm concerned about the
extra overhead of dereferencing the global. In a case like this,
does style trump the run-time efficiency (which in this case is
probably very small)?

[Toni]

En/na Mark Healey ha escrit:

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?
Very bad style. Try to avoid define as much as possible.
In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

As other have pointed out the way to do this is with a function.
Consider something like:

doMap(struct Map map)
{
int x, y;
for (x = map->X; x; --x)
for (y = map->Y; y; --y)
stuff();
}

call doMap(map) as often as you want.

Besides, I don't see you pass map, x nor y to stuff(). If you are using
global variables which are read in stuff() this is also the wrong way to
do it. Unless you have some special requirements, the right way would be:

for (x = map->X; x; --x)
for (y = map->Y; y; --y)
stuff(map, x, y);

Notice also how the "for" version is shorter than your version (3 lines
vs 10). Shorter is better as you have less places opportunity for bugs.

[Ian Collins]

Bill Pursell wrote:

I've been plagued with
a similar concern for a while now:

suppose my inner-most loop contains a single function call to
a very small function. Based on a run-time parameter, the
function changes, but for any instantiation of the program
that function remains constant. I see 2 ways to code that:

method 1)
typedef void (*my_foo)(void);
void foo1(void) { return;}
void foo2(void) { return;}
void foo3(void) { return;}

int main(int argc, char **argv)
{
my_foo select[3] = {foo1, foo2, foo3};
my_foo f;

f = select[argc-1];

do {
f();
} while (1);
}
*********************************
method 2)
int main(int argc, char **argv)
{

switch(argc) {
case 1: do foo1(); while (1);
case 2: do foo2(); while (1);
case 3: do foo3(); while (1);
}
}
In terms of style, I prefer method 1, but I'm concerned about the
extra overhead of dereferencing the global. In a case like this,
does style trump the run-time efficiency (which in this case is
probably very small)?

Every time, unless you absolutely have to optimise. Premature
optimisation is the root of (almost) all evil.

--
Ian Collins.

[Chris Hills]

In article <pa****************************@spammer.die>, Mark Healey
<di*@spammer.die> writes

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?
MISRA-C says defines should be bounded by () so that they don't have
any unexpected side effects.

If you can't put () round your define then it is probably not a safe
define and open to al sorts of invisible errors and problems.
In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

The size of the source file in a free layout language is not really
relevant.

Making them easier to read is another matter.

You could use a function in this case. unless the "stuff()" is radically
different each time. i.e. completely different number and type of
statements and functions.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[pete]

Mark Healey wrote:

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

In processing these maps I have to go over
them over and over again and
this would seriously reduce the size of the source files
I would need a special reason to consider
size of source files, as being important.
and make them easier to read.

That's what macros are all about.
If a macro makes the code easier to read, then it's being used well.
If a macro makes the code harder to read, then it's being used badly.

--
pete

[Tomás]

Mark Healey posted:

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

(You've the same name as my brother!)

Removing the typo and re-arranging the indentation:

x = map->X;

do
{
y = map->Y;

do
{
stuff();

} while (y);

x--;

} while (x);
I'm not sure if you can jump into a loop in C (you can in C++), but
nonetheless here's probably how I'd do it:

typedef int SomeType1;

typedef int SomeType2;

typedef struct Map {
SomeType1 X;
SomeType2 Y;
} Map;
inline void Mapper( Map * const p_map )
{
goto Loop1Body;

for ( SomeType1 x = p_map->X; x ; --x)
{
/* Label */ Loop1Body: /* Label */

goto Loop2Body;
for( SomeType2 y = p_map->Y; y; )
{
/* Label */ Loop2Body: /* Label */
stuff();
}
}
}

int main()
{
Map map = {};

Mapper( &map );
}
-Tomás

[Keith Thompson]

Chris Hills <ch***@phaedsys.org> writes:
[...]

MISRA-C says defines should be bounded by () so that they don't have
any unexpected side effects.

If you can't put () round your define then it is probably not a safe
define and open to al sorts of invisible errors and problems.

[...]

That's a good rule if the macro is intended to be used as an
expression. Even then, it's not always necessary; for example:
#define FALSE 0
#define TRUE 1
Putting parentheses around the integer constants would be silly, IMHO.

On the other hand, another common idiom is:

#define DO_SOMETHING(args) \
do { \
/* blah blah */ \
while (0)

This is to be used in place of a statement, not an expression. (If
MISRA-C bans this kind of macro, that's fine, but it can be useful.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Keith Thompson wrote:

Chris Hills <ch***@phaedsys.org> writes:
[...]

MISRA-C says defines should be bounded by () so that they don't
have any unexpected side effects.

If you can't put () round your define then it is probably not a
safe define and open to al sorts of invisible errors and problems.

[...]

That's a good rule if the macro is intended to be used as an
expression. Even then, it's not always necessary; for example:
#define FALSE 0
#define TRUE 1
Putting parentheses around the integer constants would be silly,
IMHO.

On the other hand, another common idiom is:

#define DO_SOMETHING(args) \
do { \
/* blah blah */ \
while (0)

This is to be used in place of a statement, not an expression. (If
MISRA-C bans this kind of macro, that's fine, but it can be useful.)

It would be more persuasive with a judicious '}' added :-)

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

Keith Thompson wrote:

[...]

On the other hand, another common idiom is:

#define DO_SOMETHING(args) \
do { \
/* blah blah */ \
while (0)

This is to be used in place of a statement, not an expression. (If
MISRA-C bans this kind of macro, that's fine, but it can be useful.)

It would be more persuasive with a judicious '}' added :-)

Well, yeah. *blush*

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Herbert Rosenau]

On Sun, 14 May 2006 06:59:08 UTC, Mark Healey <di*@spammer.die> wrote:

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

#define a macro DO_ARRAY(params...) that does all the stuff you needs
to do except stuff(). Document it well.
Replace stuff() with a macro call, name the macro so that it gets
identified as a macro easy.

#define the macro stuff() near the place it is used in MY_ARRAY - and
#undef it immediately after it is no more used.

#define the macro stuff() near the next place you needs it in
MY_ARRAY() before you calls it and #undef it when the point it is
needed is over.

Do so for all other places.

That gives you:
- one single place you have to maintain the whole MY_ARRAY
- clean macro expansion on any place you have to do different
stuff() but identical MY_ARRAY()
- you have a pice of code that is simular to selfmodifying code
but is NOT. You can replace a variable number statements with
variable meaning by having different macros (with different
parameters) on different places by simple exchanging the
content of a macro name.

Yes, you have to learn how to use the C macro processor - but that
will extend your C knowledge.

Your problem is resolved easy by planning exactly what are the
differences between each occurence of the general logic and defining
the places by name.

#define and #undef are created exactly for such cases where you have
multiple times the same code with little differences, making a single
fuction impossible or at least opaque.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Ian Collins]

Herbert Rosenau wrote:

On Sun, 14 May 2006 06:59:08 UTC, Mark Healey <di*@spammer.die> wrote:

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

#define a macro DO_ARRAY(params...) that does all the stuff you needs
to do except stuff(). Document it well.
Replace stuff() with a macro call, name the macro so that it gets
identified as a macro easy.

Why use macros when a function would do?

--
Ian Collins.

[James Dow Allen]

Richard Heathfield wrote:

Mark Healey said:

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

Why not just write a function to do this? ...
Presumably stuff() changes each time, but you could pass a function pointer
in to do the actual work.

I use this approach (though the invocation is for a line,
not a single pixel) in my image-processing library, but
only because two conditions are met: the once-per-line
processing is always the same, and it is rather involved
(buffer pointer rotation, incremental file IO, line padding,
and zigzag-adjust for hexagon-grid images).

Though I'm sure I'm in a minority (as usual!) I *avoid* the
approach (which is called what, BTW? "general cover routine"?)
when the only purpose is to avoid defining a macro, or replicating
a small amount of code. What's wrong with macros, anyway?

Even without using macros, the readability burden of replicated
code is lessened by stylistic deviations to conserve vertical
space. As a trivial example, the reader will quickly get used to
for (y = 0; y < Hei; y++)
for (x = 0; x < Wid; x++)
foobar(x, y);

when used *consistently* as a substitute for the "correct",
but space-wasting:
for (y = 0; y < Hei; y++)
{
for (x = 0; x < Wid; x++)
{
foobar(x, y);
}
}

When written "normally", an operation is invoked, controlled and
executed at a single place in the source code. Using a cover
routine, the invocation, control and execution occur in *three*
separate functions, and the reader will have to scroll or
open other files to refresh his understanding. Subdividing
functions is not an unmixed blessing -- surely good source locality
is also a virtue.

Another reason to avoid "general cover routines" is that sometimes
you need to vary the control. (I suppose "orthodox" coverers
end up with lots of seldom-needed parameters to the cover routine.)
As a case in point, recall a discussion of operating on every
element from the on-going discussion of hash table management design.
I code a straightforward loop, while my "competitor" insists that
a general cover be called. In the previous thread I indicated a
case where the general cover *cannot* work.
James Dow Allen
``Let me assert my firm belief that the only thing we have to fear
is fear itself -- nameless, unreasoning, unjustified terror which
paralyzes needed efforts to convert retreat into advance.''
-- Franklin D. Roosevelt

``When I was coming up, it was a dangerous world, and you
knew exactly who they were. It was us versus them, and
it was clear who them was. Today, we are not so sure who
the they are, but we know they're there.''
-- George W. Bush

[CBFalconer]

James Dow Allen wrote:

.... snip ...
Even without using macros, the readability burden of replicated
code is lessened by stylistic deviations to conserve vertical
space. As a trivial example, the reader will quickly get used to
for (y = 0; y < Hei; y++)
for (x = 0; x < Wid; x++)
foobar(x, y);

when used *consistently* as a substitute for the "correct",
but space-wasting:
for (y = 0; y < Hei; y++)
{
for (x = 0; x < Wid; x++)
{
foobar(x, y);
}
}

Why those distortions, when a normal and readable version is:

for (y = 0; y < Hei; y++)
for (x = 0; x < Wid; x++) foobar(x, y);
...

or even, for some devotees to useless braces:

for (y = 0; y < Hei; y++)
for (x = 0; x < Wid; x++) {
foobar(x, y);
}

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Herbert Rosenau]

On Mon, 15 May 2006 06:19:56 UTC, Ian Collins <ia******@hotmail.com>
wrote:

Herbert Rosenau wrote:

On Sun, 14 May 2006 06:59:08 UTC, Mark Healey <di*@spammer.die> wrote:

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

#define a macro DO_ARRAY(params...) that does all the stuff you needs
to do except stuff(). Document it well.
Replace stuff() with a macro call, name the macro so that it gets
identified as a macro easy.

Why use macros when a function would do?

When you have 30lines of code unchanged on 100% of usage followed by a
number of lines you knows not what that may be, followed by 31 lines
of code followed by a number of lines you knows nothing about .....

having a lot of differet variables using before, in middle of and
after the unkown points of code, whereas the unknown code uses
different variables you would never find a way to write a function
that will place in exactly the code you needs while calling it - but
having a macro the preprocessor will do that magically for you.

You'll get the variant code in place instead to have if's or case
statements.

#define M_X(a, b, c) { \
...30 lines.... \
a; \
...20 lines.... \
b; \
---44 lines---- \
c; \
---5--lines---- \
}

#define A blah = blubber(x, y, "hi, hi")
#define B(p) z = b; d = y; f(p)
#define C(t) x = a;

M_X(A, B(friend), C("hello");
#undef A
#define A printf("blah, blubber\");

M_X(A, B(sister), C("will die");

#undef B
#undef C
.........

Having all lines in M_X to handle common data makes it impossible to
write 5 functions having all the data in place without having them at
kleast at file level defined and therfor the problem that any other
function may use them without control.

Having one macro that receives the relevant differences on the
relevant places gives you any control you needs to make maintenance
easy, extend the functionality given with the known points of change.

Yes, that is nothing you would do in any application you has to write
in your live, but when you sits on a problem like the OP does it is
the solution.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Ian Collins]

Herbert Rosenau wrote:

On Mon, 15 May 2006 06:19:56 UTC, Ian Collins <ia******@hotmail.com>
wrote:

Herbert Rosenau wrote:

On Sun, 14 May 2006 06:59:08 UTC, Mark Healey <di*@spammer.die> wrote:

I have a function that runs through a two dimensional array several times.

01 x=map->X;
02 do
02 {
04 y=map->Y;
05 do
05 {
06 stuff();
07
08 }while (y);
09 x--'
10 }while(x);

Would it be considered good or bad form to #define lines 01-05 as
something like START_MAP_LOOP and lines 07-10 as END_MAP_LOOP?

In processing these maps I have to go over them over and over again and
this would seriously reduce the size of the source files and make them
easier to read.

#define a macro DO_ARRAY(params...) that does all the stuff you needs
to do except stuff(). Document it well.
Replace stuff() with a macro call, name the macro so that it gets
identified as a macro easy.

Why use macros when a function would do?

When you have 30lines of code unchanged on 100% of usage followed by a
number of lines you knows not what that may be, followed by 31 lines
of code followed by a number of lines you knows nothing about .....

having a lot of differet variables using before, in middle of and
after the unkown points of code, whereas the unknown code uses
different variables you would never find a way to write a function
that will place in exactly the code you needs while calling it - but
having a macro the preprocessor will do that magically for you.

You refactor the code to something more managable :) I've seen too many
uses of macros to cover over smelly code.

--
Ian Collins.

[James Dow Allen]

CBFalconer wrote:

James Dow Allen wrote:

Even without using macros, the readability burden of replicated
code is lessened by stylistic deviations to conserve vertical
space. As a trivial example, the reader will quickly get used to
for (y = 0; y < Hei; y++)
for (x = 0; x < Wid; x++)
foobar(x, y);

Why those distortions, when a normal and readable version is:

for (y = 0; y < Hei; y++)
for (x = 0; x < Wid; x++) foobar(x, y);

(BTW, I'm glad no one suggested the formula with a single "for"! ):
for (x = y = 0; x < Wid || (x = 0, ++y) < Hei; x++)
foobar(x, y);

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).

Anyway, the location of horizontal white space was by far the least
substantive of any issue I raised in my message: should we assume you
agree with the rest?

James Dow Allen

[Andrew Poelstra]

On 2006-05-18, James Dow Allen <jd*********@yahoo.com> wrote:

CBFalconer wrote:

James Dow Allen wrote:

> Even without using macros, the readability burden of replicated
> code is lessened by stylistic deviations to conserve vertical
> space. As a trivial example, the reader will quickly get used to
> for (y = 0; y < Hei; y++)
> for (x = 0; x < Wid; x++)
> foobar(x, y);
>

Why those distortions, when a normal and readable version is:

for (y = 0; y < Hei; y++)
for (x = 0; x < Wid; x++) foobar(x, y);

(BTW, I'm glad no one suggested the formula with a single "for"! ):
for (x = y = 0; x < Wid || (x = 0, ++y) < Hei; x++)
foobar(x, y);

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).

Anyway, the location of horizontal white space was by far the least
substantive of any issue I raised in my message: should we assume you
agree with the rest?

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.

--

Andrew Poelstra < http://www.wpsoftware.net/blog >

[Bill Pursell]

Andrew Poelstra wrote:

On 2006-05-18, James Dow Allen <jd*********@yahoo.com> wrote:

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.

[Andrew Poelstra]

On 2006-05-18, Bill Pursell <bi**********@gmail.com> wrote:

Andrew Poelstra wrote:

On 2006-05-18, James Dow Allen <jd*********@yahoo.com> wrote:

>
> 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 < http://www.wpsoftware.net/blog >

[Andrew Poelstra]

On 2006-05-18, Andrew Poelstra <ap*******@localhost.localdomain> wrote:

On 2006-05-18, Bill Pursell <bi**********@gmail.com> wrote:

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.

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

--

Andrew Poelstra < http://www.wpsoftware.net/blog >

[ais523]

Bill Pursell wrote:

#define ____ /* to denote a continued line*/
<snip>
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,
Bill Pursell <bi**********@gmail.com> wrote
in Msg. <11**********************@j55g2000cwa.googlegroups .com>

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]

Robert Latest wrote:

On 18 May 2006 09:44:43 -0700,
Bill Pursell <bi**********@gmail.com> wrote
in Msg. <11**********************@j55g2000cwa.googlegroups .com>

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

--
pete

[James Dow Allen]

Robert Latest wrote:

On 18 May 2006 09:44:43 -0700,
Bill Pursell <bi**********@gmail.com> wrote

I've never found an indentation scheme for line continuations that I like....

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]

James Dow Allen wrote:

Robert Latest wrote:

On 18 May 2006 09:44:43 -0700,
Bill Pursell <bi**********@gmail.com> wrote

I've never found an indentation scheme for line continuations that I like....

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, ...

<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]

Bill Pursell wrote:

(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.

--
pete

[Bill Pursell]

pete wrote:

Bill Pursell wrote:

(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.

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]

On 2006-05-20, James Dow Allen <jd*********@yahoo.com> wrote:

Robert Latest wrote:

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

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.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
Get your game faces on, because this is not a game.

[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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Hills]

In article <11**********************@j33g2000cwa.googlegroups .com>, Bill
Pursell <bi**********@gmail.com> writes

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?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[pete]

Chris Hills wrote:

In article <11**********************@j33g2000cwa.googlegroups .com>,
Bill
Pursell <bi**********@gmail.com> writes

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?

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

--
pete

[Keith Thompson]

"James Dow Allen" <jd*********@yahoo.com> writes:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Bill Pursell]

Chris Hills wrote:

In article <11**********************@j33g2000cwa.googlegroups .com>, Bill
Pursell <bi**********@gmail.com> writes

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?

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]

"Bill Pursell" <bi**********@gmail.com> writes:

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);

--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming

[Sjouke Burry]

Ben Pfaff wrote:

"Bill Pursell" <bi**********@gmail.com> writes:

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);

I do, and get something like this:(i 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]

Tomás wrote:

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.

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.

--
Ian Collins.

[Ben Pfaff]

Sjouke Burry <bu*************@ppllaanneett.nnlll> writes:

Ben Pfaff wrote:

"Bill Pursell" <bi**********@gmail.com> writes:

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);

I do, and get something like this:(i 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.
--
"...what folly I commit, I dedicate to you."
--William Shakespeare, _Troilus and Cressida_

[Bill Pursell]

Ben Pfaff wrote:

"Bill Pursell" <bi**********@gmail.com> writes:

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);

Generally not. I find that it often degenerates into:

long_variable_name = long_function_name (a,

b);

and I don't like the massive indent to the second argument. I prefer
to do:
long_funct_name (
a,
b,
);

and match the indentation of the closing ')' with that of the function
call
(or the variable being assigned to). I'm not entirely happy with
that style, but I prefer it to aligning with the open paren. Actually,
the
main reason I went to that style was because of the difficulty
in changing the apparent indentation with the other style. I really
work hard to have parameter lists and names short enough so
that I don't have to continue the line, which is tough considering
that I like very descriptive names and generally spell words out
completely. Thr's nthing wrse than arbtrary and incnsstnt removal
of vwls. :)

[Harald van Dijk]

Ben Pfaff wrote:

"Bill Pursell" <bi**********@gmail.com> writes:

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);

Personally, I tend to use tabs for indentation, but only for that,
exactly to avoid this kind of problem. (I also make sure my editors
show tabs.) To be specific, your example, if I would write it in your
form at all, would be
<tab>long_function_name (long_function_argument_1,
<tab> long_function_argument_2,
<tab> long_function_argument_3,
<tab> long_function_argument_4);

[Ian Collins]

Harald van Dijk wrote:

Ben Pfaff wrote:

"Bill Pursell" <bi**********@gmail.com> writes:

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);

Personally, I tend to use tabs for indentation, but only for that,
exactly to avoid this kind of problem. (I also make sure my editors
show tabs.) To be specific, your example, if I would write it in your
form at all, would be
<tab>long_function_name (long_function_argument_1,
<tab> long_function_argument_2,
<tab> long_function_argument_3,
<tab> long_function_argument_4);

How does this work with auto-indent in your editor?

--
Ian Collins.

[Harald van Dijk]

Ian Collins wrote:

Harald van Dijk wrote:

Ben Pfaff wrote:

"Bill Pursell" <bi**********@gmail.com> writes:
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);

Personally, I tend to use tabs for indentation, but only for that,
exactly to avoid this kind of problem. (I also make sure my editors
show tabs.) To be specific, your example, if I would write it in your
form at all, would be
<tab>long_function_name (long_function_argument_1,
<tab> long_function_argument_2,
<tab> long_function_argument_3,
<tab> long_function_argument_4);

How does this work with auto-indent in your editor?

After pressing Return after long_function_argument_2, I end up with one
tab, followed by a bunch of spaces, on the next line. (This is in
KDevelop.)

[Ian Collins]

Harald van Dijk wrote:

Ian Collins wrote:

Harald van Dijk wrote:

Ben Pfaff wrote:
"Bill Pursell" <bi**********@gmail.com> writes:

>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);
Personally, I tend to use tabs for indentation, but only for that,
exactly to avoid this kind of problem. (I also make sure my editors
show tabs.) To be specific, your example, if I would write it in your
form at all, would be
<tab>long_function_name (long_function_argument_1,
<tab> long_function_argument_2,
<tab> long_function_argument_3,
<tab> long_function_argument_4);

How does this work with auto-indent in your editor?

After pressing Return after long_function_argument_2, I end up with one
tab, followed by a bunch of spaces, on the next line. (This is in
KDevelop.)

Does this work if you move a bit of nested code to another indentation
level or its own function? Just curious, I've never seen an auto-indent
work with a mix of spaces and tabs.

--
Ian Collins.

[Harald van Dijk]

Ian Collins wrote:

Harald van Dijk wrote:

Ian Collins wrote:

Harald van Dijk wrote:

Ben Pfaff wrote:
>"Bill Pursell" <bi**********@gmail.com> writes:
>
>
>
>>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);
Personally, I tend to use tabs for indentation, but only for that,
exactly to avoid this kind of problem. (I also make sure my editors
show tabs.) To be specific, your example, if I would write it in your
form at all, would be
<tab>long_function_name (long_function_argument_1,
<tab> long_function_argument_2,
<tab> long_function_argument_3,
<tab> long_function_argument_4);
How does this work with auto-indent in your editor?

After pressing Return after long_function_argument_2, I end up with one
tab, followed by a bunch of spaces, on the next line. (This is in
KDevelop.)

Does this work if you move a bit of nested code to another indentation
level or its own function? Just curious, I've never seen an auto-indent
work with a mix of spaces and tabs.

No, unfortunately that doesn't seem to work properly. Depending on the
configuration, I can manage to either get the spaces replaced with a
mix of tabs and spaces, or the tabs replaced with spaces. This is after
selecting text, and then pressing the key to indent/unindent the
selection. That is what you meant, right?

[Ian Collins]

Harald van Dijk wrote:

Ian Collins wrote:

Harald van Dijk wrote:

Ian Collins wrote:
Harald van Dijk wrote:Personally, I tend to use tabs for indentation, but only for that,
>exactly to avoid this kind of problem. (I also make sure my editors
>show tabs.) To be specific, your example, if I would write it in your
>form at all, would be
><tab>long_function_name (long_function_argument_1,
><tab> long_function_argument_2,
><tab> long_function_argument_3,
><tab> long_function_argument_4);
>

How does this work with auto-indent in your editor?
After pressing Return after long_function_argument_2, I end up with one
tab, followed by a bunch of spaces, on the next line. (This is in
KDevelop.)

Does this work if you move a bit of nested code to another indentation
level or its own function? Just curious, I've never seen an auto-indent
work with a mix of spaces and tabs.

No, unfortunately that doesn't seem to work properly. Depending on the
configuration, I can manage to either get the spaces replaced with a
mix of tabs and spaces, or the tabs replaced with spaces. This is after
selecting text, and then pressing the key to indent/unindent the
selection. That is what you meant, right?

Yes. I think indentation style should be automatic, or at least lend
itself to automation, otherwise it (having to fix up manualy) becomes an
obstruction to code refactoring.

--
Ian Collins.

[Bill Pursell]

Ian Collins wrote:

Tomás wrote:

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.

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

That is definitely the key question. I think I've been
dancing around that for a long time without realizing that
the holy grail of consistent indentation is to make
that step easy. Currently, if the code I'm extracting
is someone else's, my first step is to change the
name of some of the variables so that I get compiler
errors on any line that I haven't inspected and modified.
It's a bit of a pain, but I really don't trust the copy/paste
mode of working, as way too many errors get introduced
by missing little details. If it's my own code and I know
it well enough to trust that I don't need to inspect each line,
(which is probably a bad idea regardless), I re-indent
by hand so that I get at least a cursory look at each
line to make sure I haven't done something stupid.
Usually, the mistake is that I've pushed a structure
into a function and need to replace "." with "->", which
leads to yet another syle question: I almost never
use variables that are structures. Instead, I'll use
an array of length 1 so that I never use the "." dereference,
and instead always use the arrow operator. This makes
it easier to push code into a function and somewhat
cleans up function calls, as "foo(a)" looks better
than "foo(&a)".

--
Bill Pursell

[Herbert Rosenau]

On Sat, 20 May 2006 12:25:25 UTC, "Bill Pursell"
<bi**********@gmail.com> wrote:

James Dow Allen wrote:

Robert Latest wrote:

On 18 May 2006 09:44:43 -0700,
Bill Pursell <bi**********@gmail.com> wrote
> I've never found an indentation scheme for line continuations that I like....

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, ...

<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.

Impossible mission. But I do this instead:

if (this_is_the_first_line == 5
&& this_is_the_continuation == 4
|| (another_line != last_line
&& this == that)
|| !that) {

Double indention and logical operator in front of new line when the
space of a single line is not enough to fit the complete condition.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Ian Collins]

Herbert Rosenau wrote:

On Sat, 20 May 2006 12:25:25 UTC, "Bill Pursell"
<bi**********@gmail.com> wrote:

James Dow Allen wrote:

Robert Latest wrote:

On 18 May 2006 09:44:43 -0700,
Bill Pursell <bi**********@gmail.com> wrote

>I've never found an indentation scheme for line continuations that I like....

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, ...

<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.

Impossible mission. But I do this instead:

if (this_is_the_first_line == 5
&& this_is_the_continuation == 4
|| (another_line != last_line
&& this == that)
|| !that) {

Double indention and logical operator in front of new line when the
space of a single line is not enough to fit the complete condition.

Same question I asked before, can this style be automated? It looks to
me like quite a lot of the ideas presented in this thread are write once
solutions.

--
Ian Collins.