Coding standards

[infobahn]

Re: Coding standards

Natt Serrasalmus wrote:[color=blue]
> "infobahn" <infobahn@btint ernet.com> wrote in message
> news:cqr5if$1i3 $1@sparta.btint ernet.com...
>[color=green]
>>jdallen2000@y ahoo.com wrote:
>>[color=darkred]
>>>Similarly, in C we always write "if (foo(bar))" without
>>>debating whether "if( foo (bar))" is better a priori.[/color]
>>
>>Which "we" are you talking about? It doesn't include me.
>>
>>I write if(foo(bar) != 0)[/color]
>
>
> I find that form really annoying[/color]

I don't.
[color=blue]
> and when I see it in others code. It
> suggests to me that the person who wrote it doesn't understand boolean
> variables and the C idiom that was established with the C standard library.[/color]

You are wrong to infer that. I do in fact understand boolean variables.
I also understand that in almost all cases, foo() does not return a
boolean variable, but an int. If foo() is truly boolean in nature,
then I am perfectly prepared to write if(foo(bar)) rather than
if(foo(bar) != 0)

But the fact that you find the form "annoying" suggests that you need to
relax a little.
[color=blue]
> The idiom I am referring to is that functions should return a value that
> answers the question "Did anything go wrong and if so what was it?".[/color]

Absolutely. And a boolean variable can only answer one of those
questions, which is why so few of my functions return boolean
variables.
[color=blue]
> By that
> idiom then it should be obvious to any C programmer worth their pay that
>
> if(strcmp(strin g1, string2))
>
> means "Did anything go wrong (not match up) when comparing these two
> strings?"[/color]

No, it should be obvious to any C programmer worth their pay that
the result of strcmp is not boolean, but relational (negative,
zero, or positive).
[color=blue]
> (if I wanted to know how far off they were I'd save the return
> value to a variable and evaluate that, but rarely does anyone ever care how
> far off the comparison was, other functions may have more interesting
> non-zero return codes.)[/color]

We do, however, care whether the result is negative, zero, or positive.
[color=blue]
> This form also encourages the early exit from a function:
>
> if(strcmp(strin g1, string2))
> return;[/color]

I, however, do not encourage early exit from a function. In all too
many cases, this makes the control flow harder for a maintenance
programmer to follow. Maintenance programmers are often under a lot
of pressure to fix a problem quickly, in code they don't know very
well. Anything we can do to help them out is a bonus, and writing
your functions to have all the structure of spaghetti bolognaise is
not helping anyone.
[color=blue]
> If you doubt me, look at K&R where you can find numerous examples of this
> form and the early exit from functions.[/color]

But nobody has to maintain the code in K&R's book. Also, whilst I
greatly admire both K, R, and their book, the day I use K&R as a
style guide is the day I grow an extra arm.
[color=blue]
> This may seem awkward at first, but you get used to it.[/color]

I am fortunate enough not to have got used to early exit from functions.
I am very happy for you if you are used to it, but I have developed my
own style based on my own reasoning and logic, and I'm quite happy to
use that style.

Your style for you; my style for me.
[color=blue]
> You should also get
> used to writing your own functions in the same idiom, such that they return
> zero for success and non-zero (with a value that indicates the level of
> failure) for failure. This will preserve the idiom throughout the code.[/color]

Oh, I do that already, and have done for many years.

[color=blue]
> A similar form that is particularly annoying is
>
> if(foo(bar) == TRUE) /* where true is a macro defined as some non-zero
> value */[/color]

There, I must agree with you. What makes this worse is when foo() is not
a boolean function, and yet its result is still compared against a
"boolean" symbol such as TRUE or FALSE.
[color=blue]
> {
> (indented code for the entire rest of the function)
> }
> return somestatusvaria ble;[/color]

Oh, I see. You're complaining against code structure.
[color=blue]
>
> when it should be
>
> if(!foo(bar))
> return NONZEROSTATUSVA LUE;
> (code for the entire rest of the function now not indented so far)[/color]

I prefer:

if(foo(bar))
{
rc = baz();
}
else
{
rc = NONZEROSTATUSVA LUE;
}
return rc;

Do you have a problem with the nesting depth here?

[color=blue]
> (note also that some may have different notions as to what TRUE should be
> defined as: -1, 1 etc. which makes the test against TRUE not just
> idiomatically awkward, but potentially dangerous.)[/color]

Yes, that's what I thought you meant before.
[color=blue]
>
> Even worse is
>
> if(a == b)
> {
> c = TRUE;
> }
> else
> {
> c = FALSE;
> }
>
> which should be
>
> c = a == b;[/color]

This code, whilst correct, will have the newbies (and some older hands)
reaching for their K&Rs. Better: c = (a == b);
[color=blue]
>
>
> or even worse than that
>
> if(a == b)
> {
> c = FALSE;
> }
> else
> {
> c = TRUE;
> }
>
> which should be
>
> c = !(a == b);[/color]

I would prefer c = (a != b);

[color=blue]
> Some of you may be laughing at these last two examples, but don't. I've seen
> it too many times that it's not funny any more.[/color]

I didn't find them particularly funny. Just silly.

<snip>
[color=blue][color=green]
>>
>>Hardly. It's a common style, but its mindshare seems to be diminishing.[/color]
>
>
> I hope its mindshare is dimishing. I would have written the above as:
>
> if (!cap_issubset( inheritable,
> cap_combine(tar get->cap_inheritabl e,
> current->cap_permitted) ))
> goto out;
>[/color]

Mmmm. Well, just pray you never have to maintain my code.

[color=blue]
> This way arguments to functions are lined up.[/color]

Not in my newsreader, they aren't.

[color=blue]
> There's no need for any braces
> at all,[/color]

Well, the compiler doesn't need them. The human sometimes finds them
useful, so I put them in /all/ the time.

[color=blue]
> so leave them out leaving fewer braces to worry about which ones
> match which.[/color]

For a start, they should be close enough together that you can
see which ones match which other ones. And even if they aren't,
if you line them up
{
like this
}

you don't have to worry about which ones match which, because it's
obvious. And even if it weren't obvious, decent modern editors can
whizz you from { to } and back in the blinking of an eye.

<snip>
[color=blue][color=green][color=darkred]
>>>I know almost nothing about the `indent' utility. Can it produce
>>>the spacing above automatically? And suppress it when shorter
>>>names make it unnecessary? I know about `#ifndef lint'; is there
>>>some sort of `#ifndef indent' when one wants to preserve a helpful
>>>white-space arrangement?[/color]
>>
>>The whole point of indent is that you run code through it to
>>convert it to your style, making it easier for you to read.
>>Then, if you need to check it back into CVS, you run the
>>code through it again, this time to convert it to the house
>>style. That way, you don't screw up diff with mere whitespace
>>changes, and everyone's happy. Bye bye holy war.[/color]
>
>
> I do agree with you on that.[/color]

Hallelujah, and amen.

[E. Robert Tisdale]

Re: Coding standards

Natt Serrasalmus wrote:
[color=blue]
> infobahn wrote:
>[color=green]
>> I write
>>
>> if(foo(bar) != 0)[/color]
>
> I find that form really annoying and when I see it in others code.
> It suggests to me that
> the person who wrote it doesn't understand boolean variables
> and the C idiom that was established with the C standard library.[/color]

Idioms are for idiots!
[color=blue]
> The idiom I am referring to is that functions should return a value that
> answers the question, "Did anything go wrong and, if so, what was it?".[/color]

That's two questions.
[color=blue]
> By that idiom then it should be obvious to any C programmer worth their pay that
>
> if (strcmp(string1 , string2))
>
> means "Did anything go wrong (not match up) when comparing these two strings?"[/color]

Because the result returned by strcmp is not zero
and any non zero result used as a conditional
is [implicitly] converted to true.
[color=blue]
> (if I wanted to know how far off they were,
> I'd save the return value to a variable and evaluate that
> but rarely does anyone ever care how far off the comparison was,
> other functions may have more interesting non-zero return codes.)[/color]

Unfortunately, the rest of us must write code
that is obvious to C programmers *not* worth their pay
as well as C programmers who are worth their pay.
This means that I write explicit code
rather than relying upon implicit conversions.
I would write:

if (0 != strcmp(string1, string2))

to detect strings which don't match.

It isn't my responsibility to ferret out incompetent programmers.
And I don't think that it helps to make competent programmers
work any harder than necessary to understand my intent.

My advice is, "Don't write code
that relies on competent C programmers to maintain it."
Spell it out if it is possible that
some programmer might misinterpret your intent.

[Alan Balmer]

Re: Coding standards

On 29 Dec 2004 21:58:30 EST, "Natt Serrasalmus"
<Nserrasalmus@c haracoid.com> wrote:
[color=blue]
> the C idiom that was established with the C standard library.
>The idiom I am referring to is that functions should return a value that
>answers the question "Did anything go wrong and if so what was it?"[/color]

But that's just not true, except for the I/O functions. Most others
return some value as a result, not as a diagnostic.

I will write "if (a)" providing 'a' is a boolean. If not, I will write
if (a != 0). If that bothers you, so be it.

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Albert van der Horst]

Re: Coding standards

In article <cq51f2$b5b@dis patch.concentri c.net>,
Natt Serrasalmus <Nserrasalmus@c haracoid.com> wrote:[color=blue]
>
>a = (b == c) ? d : e;[/color]


a = b==c ? d : e;

Groetjes Albert

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

[Albert van der Horst]

Re: Coding standards

In article <cq5aec$2lt@lib rary1.airnews.n et>,
Gordon Burditt <gordonb.2t38e@ burditt.org> wrote:[color=blue]
>
>When you've started nesting ?:, though, you've probably gone too far.[/color]

pc = 1==x? "one" :
2==x? "two" :
3==x? "three" :
4==x? "five" ;

I find this nesting acceptable, even if it goes on indefinitely.
[color=blue]
> Gordon L. Burditt[/color]

Groetjes Albert

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

[E. Robert Tisdale]

Re: Coding standards

Albert van der Horst wrote:
[color=blue]
> Natt Serrasalmus wrote:
>[color=green]
>>a = (b == c) ? d : e;[/color]
>
> a = b==c ? d : e;[/color]

a = (b == c)? d: e;

Is the space before terminators like ? and : a European thing?

[Stephen Sprunk]

Re: Coding standards

"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
news:cr4f9h$nta $1@nntp1.jpl.na sa.gov...[color=blue]
> Albert van der Horst wrote:
>[color=green]
> > Natt Serrasalmus wrote:
> >[color=darkred]
> >>a = (b == c) ? d : e;[/color]
> >
> > a = b==c ? d : e;[/color]
>
> a = (b == c)? d: e;
>
> Is the space before terminators like ? and : a European thing?[/color]

Apparently not, since I do it as well and I'm not European. However, aren't
? and : parts of a ternary _operator_, not _terminators_?

Would you write "a = b+ c;" or "a = b + c;" ? I prefer the latter, and
consider ? and : to be equivalent for formatting purposes.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

[E. Robert Tisdale]

Re: Coding standards

Stephen Sprunk wrote:
[color=blue]
> E. Robert Tisdale wrote:
>[color=green]
>>Albert van der Horst wrote:
>>[color=darkred]
>>>Natt Serrasalmus wrote:
>>>
>>>>a = (b == c) ? d : e;
>>>
>>>a = b==c ? d : e;[/color]
>>
>> a = (b == c)? d: e;
>>
>>Is the space before terminators like ? and : a European thing?[/color]
>
>
> Apparently not, since I do it as well and I'm not European.
> However, aren't ? and : parts of a ternary _operator_, not _terminators_?
>
> Would you write "a = b+ c;" or "a = b + c;" ? I prefer the latter,
> and consider ? and : to be equivalent for formatting purposes.[/color]

Personally, I try to use the same punctuation rules
that are used for ordinary (mathematical) typesetting.
Here are my recommendations :

Terminators always follow immediately after an expression

x@ for all @ in {?, :, ,, ;}

and are followed by at least one white space.
Write

x? y: z

instead of

x ? y : z

or

x?y:z

and write

void f(int, int, int); void g(double);

instead of

void f(int,int,int); void g(double);

for example.

There is no space
between some binary operators and their operands

x@y for all @ in {::, ., ->, .*, ->*, *, /, %, &, ^, |}

but there is always a space
between other binary operators and their operands

x @ y for all @ in {+, -, <<, >>;, <, <=, >, >=, ==, !=,
&&, ||, =, *=, /=, %=, +=, -=, <<=, >>=, &=, |=, ^=}

except when expressions appear as subscripts.
Write

x + y

instead of

x+y
and

x*y

instead of

x * y

for example.
But you may wish to write

A[i+1][j-1]

instead of

A[i + 1][j - 1]

for example to subscript array A.


Most unary prefix operators never have any whitespace
between themselves and their operands

@x for all @ in {::, ++, --, ~, !, -, +, &, *}

but others do

@ x for all @ in {sizeof, new, delete, delete [], throw}

No unary postfix operators

x@ for all @ in {[], (), ++, --}

ever have any whitespace between themselves and their operands.

Use the normal typesetting rules for parentheses (),
square brackets [], angle brackets <> and curly brackets {}.
No space after (, [, < or { and no space before ), ], > or }.
Write

(x)

instead of

( x )

or

(x )

or

( x)

and write

[x]

instead of

[ x ]

or

[x ]

or

[ x]

for example.
There are, of course, exceptions
where extra white space helps to make your code more readable:

double A[2][3] = {{ 1, -1, 0},
{-10, 11, -21}};

[Stephen Sprunk]

Re: Coding standards

"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
news:cr4pcr$smb $1@nntp1.jpl.na sa.gov...[color=blue]
> Stephen Sprunk wrote:[color=green]
> > Apparently not, since I do it as well and I'm not European.
> > However, aren't ? and : parts of a ternary _operator_, not
> > _terminators_?
> >
> > Would you write "a = b+ c;" or "a = b + c;" ? I prefer the latter,
> > and consider ? and : to be equivalent for formatting purposes.[/color]
>
> Personally, I try to use the same punctuation rules
> that are used for ordinary (mathematical) typesetting.[/color]

Except many operators in C are not ordinary mathematical symbols or may have
non-math meanings in certain contexts.
[color=blue]
> Here are my recommendations :
>
> Terminators always follow immediately after an expression
>
> x@ for all @ in {?, :, ,, ;}
>
> and are followed by at least one white space.[/color]

I agree, except I don't consider ? and : to be terminators -- they're a
ternary operator, which I treat the same as your second group of binary
operators.
[color=blue]
> There is no space
> between some binary operators and their operands
>
> x@y for all @ in {::, ., ->, .*, ->*, *, /, %, &, ^, |}[/color]

I'd move the "math" binary operators, *, /, % and the bitwise operators &,
^, | to the following group.
[color=blue]
> but there is always a space
> between other binary operators and their operands
>
> x @ y for all @ in {+, -, <<, >>;, <, <=, >, >=, ==, !=,
> &&, ||, =, *=, /=, %=, +=, -=, <<=, >>=, &=, |=, ^=}
>
> except when expressions appear as subscripts.[/color]

Or when the use of whitespace decreases readability, common when there are
multiple levels of parens.
[color=blue]
> Most unary prefix operators never have any whitespace
> between themselves and their operands
>
> @x for all @ in {::, ++, --, ~, !, -, +, &, *}[/color]

I'd thought a space wasn't legal for these, but my compiler seems to accept
one; it never occurred to me to separate unary operators from their
operands.
[color=blue]
> but others do
>
> @ x for all @ in {sizeof, new, delete, delete [], throw}[/color]

I use the function-like variant of sizeof so I hadn't thought of that; new,
delete, delete[], and throw are not operators in C.
[color=blue]
> No unary postfix operators
>
> x@ for all @ in {[], (), ++, --}
>
> ever have any whitespace between themselves and their operands.
>
> Use the normal typesetting rules for parentheses (),
> square brackets [], angle brackets <> and curly brackets {}.
> No space after (, [, < or { and no space before ), ], > or }.[/color]

I agree for parens and square brackets, but disagree for angle and curly
brackets. I treat < and > the same as other "math" operators, and I always
put whitespace before/after { and } unless it severely detracts from
readability.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

[Trent Buck]

Re: Coding standards

Up spake Stephen Sprunk:[color=blue][color=green]
> > Most unary prefix operators never have any whitespace
> > between themselves and their operands[/color]
>
> I'd thought a space wasn't legal for these, but my compiler seems to accept
> one; it never occurred to me to separate unary operators from their
> operands.[/color]

A common parsing technique is to convert text into tokens (discarding
whitespace along the way), then search the sequence of tokens for
patterns. Compilers implemented in this way don't care about
whitespace, only separators between tokens.

An example lexical analyzer might produce the following

"!foo" ==> EXCLAM IDENTIFIER
"! foo" ==> EXCLAM IDENTIFIER
"foo bar" ==> IDENTIFIER IDENTIFIER
"foobar" ==> IDENTIFIER

(C ignores whitespace because the standards says so, but the above might
be considered a `rationale'; in, say, lex+yacc, it's easier to write
that way.)

--
-trent
<foo> ...caffine is far less deadly.
<bar> Not if you smoke it!

[Christian Bau]

Re: Coding standards

In article <lnvfakcw3u.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.org> wrote:
[color=blue]
> "Natt Serrasalmus" <Nserrasalmus@c haracoid.com> writes:[color=green]
> > "infobahn" <infobahn@btint ernet.com> wrote in message
> > news:cqr5if$1i3 $1@sparta.btint ernet.com...[/color]
> [...][color=green][color=darkred]
> >> Which "we" are you talking about? It doesn't include me.
> >>
> >> I write if(foo(bar) != 0)[/color]
> >
> > I find that form really annoying and when I see it in others code. It
> > suggests to me that the person who wrote it doesn't understand boolean
> > variables and the C idiom that was established with the C standard library.
> > The idiom I am referring to is that functions should return a value that
> > answers the question "Did anything go wrong and if so what was it?". By
> > that
> > idiom then it should be obvious to any C programmer worth their pay that
> >
> > if(strcmp(strin g1, string2))
> >
> > means "Did anything go wrong (not match up) when comparing these two
> > strings?" (if I wanted to know how far off they were I'd save the return
> > value to a variable and evaluate that, but rarely does anyone ever care how
> > far off the comparison was, other functions may have more interesting
> > non-zero return codes.)[/color]
>
> Personally, I don't think of the result of strcmp() as a boolean
> value. It's effectively a tri-state value, one of <0, 0, or >0
> depending on the result of the comparison. I prefer an explicit
> comparison:
>
> if (strcmp(string1 , string2) != 0) ...
>
> If the function's name implied that it tests whether the arguments
> differ, I might feel differently about it.[/color]

First, by definition it is a multi-valued function and not a boolean
function. Second, if it was a boolean function, then the person who
called it "strcmp" and not "strnotequa l" should be shot.

[Dietmar Schindler]

Re: Coding standards

Stephen Sprunk wrote:[color=blue]
> I use the function-like variant of sizeof ...[/color]

There is no function-like variant of sizeof.

[Richard Bos]

Re: Coding standards

"Stephen Sprunk" <stephen@sprunk .org> wrote:
[color=blue]
> "E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
> news:cr4f9h$nta $1@nntp1.jpl.na sa.gov...[color=green]
> > Albert van der Horst wrote:
> >[color=darkred]
> > > Natt Serrasalmus wrote:
> > >
> > >>a = (b == c) ? d : e;
> > >
> > > a = b==c ? d : e;[/color]
> >
> > a = (b == c)? d: e;
> >
> > Is the space before terminators like ? and : a European thing?[/color]
>
> Apparently not, since I do it as well and I'm not European.[/color]

Whereas I don't do it, and I am.
[color=blue]
> However, aren't ? and : parts of a ternary _operator_, not _terminators_?[/color]

Yes, but their use in natural language makes a? b: c more comfortable to
me than a ? b : c.

Richard

[Richard Bos]

Re: Coding standards

Dietmar Schindler <dSpam@arcor.de > wrote:
[color=blue]
> Stephen Sprunk wrote:[color=green]
> > I use the function-like variant of sizeof ...[/color]
>
> There is no function-like variant of sizeof.[/color]

There's a way to use sizeof that looks as if it's a function call. For
types, it's required. For expressions, it's a consequence of the fact
that (exp) is, to all intents and purposes, the same thing as exp.

Richard

[jdallen2000@yahoo.com]

Re: Coding standards

[color=blue]
> The idiom I am referring to is that functions should return a
> value that answers the question "Did anything go wrong and
> if so what was it?".[/color]

Tend to give the function a name that sounds like a predicate; i.e.
isvalid(...) would obviously return true on success; you might
use isntvalid() to cope, but often a *successful* function
won't want to return zero on success -- it will have a story
to tell.
[color=blue]
> [True Style] is a common style, but its mindshare seems to
> be diminishing.[/color]

I'll believe you, though it saddens me. Pursuing the analogy
with English, frequent misspellings eventually make their
way into the dictionary, but that doesn't make misspelling
right.
[color=blue]
> there is no standard for C style[/color]

I hope we're not quibbling over a definition of "standard."
The True Style was never universally agreed, of course,
but was in very widespread use among the most elite C
programmers. Good and bad code may be written in any
style of course, but I'm sure there is (was?) a strong
positive correlation between coding in True Style and
positive traits like clarity and modularity. (I'm not
saying True Style is intrinsically conducive to good
coding practice, just that those who use it tend to have
learned from or emulate the Masters.)

Anyway, True Style certainly *was* a standard at Sun Microsystems,
a large company founded by one of the greatest Names in Unix history.
I'd expected any style mandate to be annoying but quickly became
a fan of True Style. Here are my reasons:

(1) I was mostly observing this style already, a major
exception being brace placement. I was writing
}
else
{
but in True Style this is written
} else {
The second form is simply better than the first! The former
form disconnects the keyword "else" from both its antecedent
and postcedent and is distracting to read. Also it wastes
two lines on the screen compared with the latter form, and this
is a "big deal." The left-braces in Non-true code use up
considerable vertical space and therefore more scrolling is
needed to understand a function. Smaller fonts might alleviate
this problem, but that's not an option for those of us
with poor eyesight. (Rarely, I may even run statements
together on the same line, when the statements are *very* similar,
very short, and obviously coupled.)

(2) I was proud to emulate the style of so many Masters.

(3) As I examined various software I noticed the strong correlation
between True Style and good traits like clarity and modularity.
True Style became, in my mind, a badge of honor indicating
that software deserved to be taken seriously. Linus Torvalds
also codes in True Style, so I don't think this is just a
Berkeley/Bell-Labs phenomenon.

(4) Whitespace arrangement isn't all that important but
uniformity would be convenient.
Why did all you apostates insist on deviating anyway? :-)

* * * * * * * * * * * * * * * * *

Although defense counsel continues to recommend `indent'
they offered no rebuttal to this point:
[color=blue]
> When I nest expressions of (x ? y : z), I tend to use
> line-breaks and spacing to make the logic easy-to-see.
> Maybe that's why the `indent' fans seemed to disparage
> such nesting -- in their environment the helpful spacing
> will tend to be expunged![/color]

Are we to conclude that the defendants are satisfied to use
only indent-approved spacing? Who's being dogmatic here, anyway?

* * * * * * * * * * * * * * * * *

15 months ago, in comp.programmin g about "bracket convention"
I mentioned a stylistic deviation I use, and one of the
defense attorneys in the present case then responded:[color=blue]
> Blech.[/color]

Let me show this code again, my way and in an "approved style."
(Some of you may not have processed images or other arrays
with multiple homogeneous dimensions, but simple nested for-loops
are a very common idiom in such applications.)

I'm curious if any newsgrouper actually believes the "approved"
coding is more readable here.

My way:
/*
* Do a 3-D convolution.
* Convolve in_sig with conv_k producing out_sig.
* (Delivered code may be slightly different, for performance.)
*/
for (x = in_sig->beg_x; x < in_sig->end_x; x++)
for (y = in_sig->beg_y; y < in_sig->end_y; y++)
for (z = in_sig->beg_z; z < in_sig->end_z; z++) {
val = 0;
for (dx = conv_k->beg_x; dx < conv_k->end_x; dx++)
for (dy = conv_k->beg_y; dy < conv_k->end_y; dy++)
for (dz = conv_k->beg_z; dz < conv_k->end_z; dz++) {
val += in_sig->dat[x+dx][y+dy][z+dz]
* conv_k->dat[dx][dy][dz];
}
out_sig->dat[x][y][z] = val;
}


"Approved" style:
for (x = in_sig->beg_x; x < in_sig->end_x; x++)
{
for (y = in_sig->beg_y; y < in_sig->end_y; y++)
{
for (z = in_sig->beg_z; z < in_sig->end_z; z++)
{
val = 0;
for (dx = conv_k->beg_x; dx < conv_k->end_x; dx++)
{
for (dy = conv_k->beg_y; dy < conv_k->end_y; dy++)
{
for (dz = conv_k->beg_z; dz < conv_k->end_z;
dz++)
{
val += in_sig->dat[x+dx][y+dy][z+dz]
* conv_k->dat[dx][dy][dz];
}
}
}
out_sig->dat[x][y][z] = val;
}
}
}


I understand that many people, including True Stylists, will
deprecate my peculiar for-nesting, especially since the lack of
braces or indentation tends to hide the nesting. FWIW, I *never*
omit the new-line before a for-body, even if it's the trivial
for-body (";"), so (in my private universe) consecutive for's as
above will *always* be nested.

* * * * * * * * * * * * * * * * *

Finally, do let's put the small matter of source code white-space
in perspective. I'll cheerfully denounce True Style if the rest of
you will denounce the insane politics which have mesmerized a
once-great nation.
Best wishes for a Truly Stylish and Happy New Year
James Dow Allen