The world's evilest code formatting style

[red floyd]

Correct formatting is:

void Whatever()
{
for (int i = 0; i < 100; i++)
{
printf("whatever\n");
}
}

And technically, its impolite to brace single lines (single SOURCE lines,
not single code lines... ie... if your single line of source wraps multiple
lines, it should be braced), but in the above case... CORRECT & POLITE
formatting is:

void Whatever()
{
for (int i = 0; i < 100; i++)
printf("whatever\n");
}

Except for when your project's official style guide says, "Thou *SHALT*
enclose if statements and for loops in braces."

 

[mlimber]

The final revelation which made me stop was that the style does not
support inline blocks, which in turn means it doesn't support the
important guideline

* in C++, declare variables close to their first usage, and limit
their scopes as much as practically possible.

E.g., the code

for( int i = 0; i < 100; ++i )
{
std::cout << "whatever\n";
{
double const x = f( i );
// Do things with x
}
{
double const y = f( i );
// Do things with y
}
}

becomes less than readable with the indented braces style,

for( int i = 0; i < 100; ++i )
{
std::cout << "whatever\n";
{
double const x = f( i );
// Do things with x
}
{
double const y = f( i );
// Do things with y
}
}

Not that this kind of thing occurs very often in practice, but it's the
principle.

I agree with your principle, certainly, but in multithreaded
programming, local blocks like that are not so rare if a ScopedLock
pattern is used (see, e.g., Boost.Threads' boost::mutex::scoped_lock
which is demonstrated here
http://www.ddj.com/showArticle.jhtml?documentID=cuj0205kempf&pgno=5).

Cheers! --M

 

[Marcus Kwok]

So Kernighan and Ritchie - the two guys who *invented C* - are just
"dumb beyond dumb" eh?

You do relaize that style is called the Kernighan and Ritchie (K&R)
Style right?

If the style can't stand on its own without an appeal to authority then
it can't stand on its own. [...]
I'll leave you to your hero worship and remain...unconvinced.

If the style can't stand on its own without an ad hominem argument then
it can't stand on its own either.

I can see benefits and disadvantages to both styles.

The most important thing IMHO is that the style has a valid rationale,
and that it is applied consistently to a body of code. As I see it,
both styles have valid rationales (though with slightly different aims).

 

[Noah Roberts]

The most important thing IMHO is that the style has a valid rationale,
and that it is applied consistently to a body of code.

I don't see that it even needs to be applied consistently. I run into
lots of code with a miriad of brace styles and I hardly even
notice...except I don't like the right bracing. But either way I can
read it and even when a function has two or more brace styles in it I
haven't found it any harder to read.

 

[JustBoo]

What does that matter?
Answer: not a damn thing.

If the style can't stand on its own without an appeal to authority then
it can't stand on its own. I'm not ready to bow down and worship K&R
or Bjarne.

Umm, well what can you say to that. Man.... Perhaps someone has
messianic issues?

Hint: You are NOT the chosen one.

He was the sort of person who stood on mountaintops during
thunderstorms in wet copper armour shouting "All the Gods are
bastards." - Terry Pratchett

 

[Noah Roberts]

Umm, well what can you say to that. Man.... Perhaps someone has
messianic issues?

Hint: You are NOT the chosen one.

I'll just say that is quite a leap and leave it at that. You're way
too invested in this silly issue.

 

[JustBoo]

I'll just say that is quite a leap and leave it at that. You're way
too invested in this silly issue.

Now you're indulging in Psychological Projection. The very behavior
you're accusing me of is actually your behavior. Let's review shall
we.

Who just went on an emotional rant that had little to do with
programming and everything to do with "hero" worship.

Let's see, it was not me, so that only leaves... you. I hope you can
figure out the rest on your own. Well, probably not….

Men occasionally stumble over the truth, but most
of them pick themselves up and hurry off as if
nothing had happened. - Winston Churchill

 

[Ron House]

Ron House wrote:




I'm sorry, but despite you have taught classes, you seem to have avoided
teaching me exactly what style you are talking about.

Please just write your favorite kind of if{} block here, without lectures or
alternatives. I promise not to bust on it.

if (...) {
...
} else if (...) {
...
} else if (...) {
...
} else {
...
}

There are four line-oriented cookie-cutter templates here:

start if
else if
else
end if

Some languages define special keywords for these, but with this
line-oriented discipline, it is safe and readable. The only statement
allowed after else without a protecting set of braces is another if, and
that too only if it is written using the line-oriented template. So,

if (...) {
...
} else
if (...) {
...
}

is not allowed.

 

[Ron House]

[/QUOTE]

>...

And technically, its impolite to brace single lines (single SOURCE lines,
not single code lines... ie... if your single line of source wraps multiple
lines, it should be braced), but in the above case... CORRECT & POLITE
formatting is:

void Whatever()
{
for (int i = 0; i < 100; i++)
printf("whatever\n");
}

And here we have the source of countless runtime errors. Needless to
say, anyone who thinks the safest style is "dumb beyond dumb" (not to
mention USING CAPS) will zero in infallibly on one of the most
error-prone and inconsistent styles possible.

 

[Noah Roberts]

Well, since we can't agree on bracing, and it is soooooo important....I
say we stop using them:

int main()
<%
int x;
if (x = 1) <% cerr << "OH SHIT!!\n"; %>

return 0;
%>

 

[Frederick Gotham]

Noah Roberts posted:

I would really like to meet the person who knows what this code does
without having to do a double or triple take at least.

for(size_t r=0;r<m_row;++r)for(size_t c=0;c<m_col;++c) (*this)[r][c] =
src[r][c];

I don't mean to boast, but the meaning of that line is pretty clear to
me.

For each iteration of the loop, there is an inner loop within which an
assignment is performed. I'd separate the lines and indent however:

for( size_t r = 0; r != m_row; ++r )
for( size_t c = 0; c != m_col; ++c )
(*this)[r][c] = src[r][c];

dynamic_2d_array(const
dynamic_2d_array&src):m_row(src.m_row),m_col(src.m_col),
m_data((src.m_row!=0&&src.m_col!=0)?new T[src.m_row*src.m_col]:NULL)

I don't think any programmer in their right mind would say whitespace
is THAT scarce.

Once can become accustomed to reading code which contains the minimum
whitespace, things like:


a=b*c+4/2;

That is 148 characters, all on one line, not including
the indentation before the first character or the brace that
immediately follows.

I keep my line width below 80.

 

[Frederick Gotham]

Nobody posted:

Although that sucks... its not as bad as people who "right brace"...
so called "right bracers"... ie:

void Whatever() {
for (int i = 0; i < 100; i++) {
printf("whatever\n");
}
}

I use next-line braces for functions, or anything which contains
executable code, e.g.:


void ArbitraryFunc()
{
do
{
/* Loop Body */
} while ( /* Condition */ );


for(;
{
/* Loop Body */
}

}


And line-edge braces everywhere else:


struct ArbitraryStruct {
/* Members */
};

union ArbitraryUnion {
/* Members */
};

namespace ArbitraryNamespace {

}

 

[Noah Roberts]

Noah Roberts posted:

I would really like to meet the person who knows what this code does
without having to do a double or triple take at least.

for(size_t r=0;r<m_row;++r)for(size_t c=0;c<m_col;++c) (*this)[r][c] =
src[r][c];

I don't mean to boast, but the meaning of that line is pretty clear to
me.

For each iteration of the loop, there is an inner loop within which an
assignment is performed. I'd separate the lines and indent however:

for( size_t r = 0; r != m_row; ++r )
for( size_t c = 0; c != m_col; ++c )
(*this)[r][c] = src[r][c];

Yes, that makes it much more clear. The point isn't that _I_ can't
read and understand the code; the point is that it is much more
difficult to because of the piss poor coding style.

Yes, it is relatively simple code and anyone experienced can read it
but try the bug test someone else posted here in this thread and tell
us how long it took you to find the error.

Even experienced coders hate sifting through spaghetti...especially
when there is no need.

 

[Kaz Kylheku]

C++ers:

Feast your eyes:

void Home::
inherits (IdentifierPtr const& id)
{
...
}

For those of you who haven't figured it out yet, that's the method
Home::inherits().

I suppose the theory is that Home:: is an enclosing type, so it should
pretend to wrap the method, like a namespace.

I have a simpler explanation. Someone blindly ran a C formatting tool
on C++ code.

There is a traditional C style in which the indentifier in a function
definition is placed at the beginning of a line. This style is used in
C++ also, but it looks like this:

void
Home::inherits(...)
{
}

Some dumb code formatting tool for C might get confused and treat the
Home and :: as part of the declaration specifier list.