The world's evilest code formatting style

[kwikius]

If you are near Southern California I can save you 1 grand. ;-)

http://www.zeroplayer.com/cgi-bin/wiki?TestFirstUserInterfaces

Aint you one of the guys always telling everyone how O.T. they are...



regards
Andy Little

 

[Pavel Vozenilek]

How about this:

void f()
{
if (preconfail)
goto end;

while (something)
{
... do stuff
if (whatever)
goto end;
}

if (more stuff)
{
do X;
}
else
{
goto end;
}

end:
return;
}

Yes, I in fact ran into that in the REAL world.

If this was C++ then the C programmer had lied on his resume.

For C it is quite handy.

/Pavel

 

[Phlip]

How about this:

void f()
{
if (preconfail)
goto end;

while (something)
{
... do stuff
if (whatever)
goto end;
}

if (more stuff)
{
do X;
}
else
{
goto end;
}

end:
return;
}

Yes, I in fact ran into that in the REAL world.

Tsk tsk, you're right. That function is WAY too long!

 

[Phlip]

Then why, for functions, they put brackets on a new line. If it was just
to
save vertical space, why not be consistent?

And what's wrong with saving vertical space again?


If this was C++ then the C programmer had lied on his resume.

For C it is quite handy.

It's either a vestige of the C version of a 'finally' block (with nothing in
the block), or a feeb attempt to follow the "one entry one exit" rule
without understanding it.

 

[peter koch]

John L Fjellstad skrev:

Then why, for functions, they put brackets on a new line. If it was just to
save vertical space, why not be consistent?

And what's wrong with saving vertical space again?

One nice argument is that vertical space in programs is quite cheap
these days. If you compare it with vertical space in books the rate has
been declining quite a lot during the last 50 years. So if you find
even the slightest advantage of a (almost) blank line, just be brave
and put it there.

/Peter

 

[persenaama]

I'm the main author of the following smart pointer class:
http://axter.com/smartptr
Amazing..


But at least I know how to make code that compiles, and I know simple
C++ rules like the order of construction, which you obviously did not
know in you're other post.

Impressive.

The customer doesn't care how pretty your source code looks. The
customer just wants it to work, and work fast.

Ours do, they use the code in their products.

I don't see how less readable sourcecode helps towards the goal of
robust and efficient program development, in itself ofcourse it is not
the goal but a tool to meet the expectations.

 

[Earl Purple]

How about you all ready this section of the FAQ:

http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.10

True it is hidden away there and not in the "coding standards" chapter
where I think it belongs.

 

[JustBoo]

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

Thats just dumb beyond dumb. A guy I worked with actually said he does it
like that because "putting it on the next line just wastes a line". I'm
thinking the fact that he has a brain is just a waste of precious brain
cells that others could better utilize.

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?

 

[JustBoo]

Can anyone think of an eviler style, seen in published code? ;-)

Worked with an Optics PhD once. He was absolutely convinced that how
you formatted your code impacted how fast it would run. I'm not
kidding.

Dr. Tang are you still out there?

Consequently, virtually no whitespace, and here's the best part,
whenever he coded a switch/case each case was on it's own line no
matter how long.

switch( x ) {
case 1: code code code code code code code code to infinity;
case 2: code code code code code code code code to infinity;
}

And mind you he had functions, comments, etc., hell, he had small
novella's on each of those lines. It was laughably sad. No one could
tell him any different either. He would not listen.

 

[mlimber]

[mindlessly copied original post redacted]

Redaction connotes emmending, not snipping. Try "elided". ;-)

Not so. See, e.g.,

http://searchcio.techtarget.com/sDefinition/0,,sid19_gci1029839,00.html

Cheers! --M

 

[John L Fjellstad]

On a computer screen, a little more vertical space, and {} in at least
the same column, make things a little more readable.

Interesting enough, I found these old source code for a C compiler
(written by Ritchie, I'm guessing), using the right brackets.
http://minnie.tuhs.org/UnixTree/EarlyC/

If it's good enough for the originators of the language, it's good
enough for me

I just don't think the brackets on the new line is necessary (just
IMO). If you are trying to match, the closing bracket should match the
first statement in the same column.

if (something) {
...
}

closing bracket can only match the if. Put the opening bracket on the
same line doesn't provide any extra info. For me, at least, it doesn't
make it more readable, but it does make it more scrollable.

Then again, I just read some source code that went something like this

if (something)
{
...
}
else if (somethingelse)
{
...
}
else
{
...
}

Suddenly, you have to scroll like a champ.

Oh, well, ce la vie

 

[Earl Purple]

Worked with an Optics PhD once. He was absolutely convinced that how
you formatted your code impacted how fast it would run. I'm not
kidding.

Dr. Tang are you still out there?

Consequently, virtually no whitespace, and here's the best part,
whenever he coded a switch/case each case was on it's own line no
matter how long.

switch( x ) {
case 1: code code code code code code code code to infinity;
case 2: code code code code code code code code to infinity;
}

And mind you he had functions, comments, etc., hell, he had small
novella's on each of those lines. It was laughably sad. No one could
tell him any different either. He would not listen.

He may have worked in the past with interpreted languages - in a fully
interpreted language that can sometimes be the case. Not sure there are
many of those anymore.

There was a time once in some language where shorter identifiers also
meant more efficient code.

 

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

And if you add in similar styles for C++ constructs, you get
"Stroustrup" style:

http://www.research.att.com/~bs/bs_faq2.html#layout-style

I do not believe that Dr. Stroustrup is "dumb beyond dumb" either.

 

[Phlip]

Interesting enough, I found these old source code for a C compiler
(written by Ritchie, I'm guessing), using the right brackets.
http://minnie.tuhs.org/UnixTree/EarlyC/

On a modern computer screen...

 

[Noah Roberts]

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?

What does that matter? No, really. Just how significant is the
styling of one individual, no matter whether they invented the language
I write in or not (not) have to do with what I find more readable?

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. I am fully ready to accept that they may do things in error
or have opinions that are just dumb. Unless they are gods, and I don't
believe that is such, then it is to be expected.

I'll leave you to your hero worship and remain...unconvinced.

 

[Mike Smith]

I rather have a programmer who understands beginners C++ language
rules, then someone who knows how to right pretty code that doesn't
compile or is inefficient because they don't understand the language.

I'd rather have a programmer who understands that code, once written,
will be maintained, extended, and otherwise dealt with by *other
people*, and that that code should be written so as to *facilitate*, not
hamper, those activities. I'd also rather have a programmer who isn't a
totally arrogant bastard, and who shows some sign of ability to play
well with others.

 

[Mike Smith]

No, actually, most coders (including myself) don't give a bucket of canadian
moose piss about that and only care that they can maintain the code (to
protect their jobs in times of layoff). Being "the only one who can rapidly
work on this code" saved my ass in the last round of layoffs at my company
and the CEO himself even told me so himself. Its not that I write poor code,
in fact, I take time to VERY nicely format and comment code... when its
something *I* care about... like my personal projects. Going hogwild with
stylization and comments and formatting at work? Why bother? Selfish
attitude? of course... same attitude as every company has towards its
employees. Am I still employed while more concientious workers were let go?
Yup...

And anyone here who tells me they dont have this attitude is full of it...
someone at my work who EVERYBODY there considers the most concientious
worker recently confessed to me that he just gives that appereance, but
doesn't give a crap about the company or the product as long as he is
working on something interesting...

Remind me never to hire you.

 

[Mike Smith]

your example, another style might write:

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

But of course, no one does, precisely because of two wasted lines.

I do. (Except, of course, that *EVERYBODY KNOWS* that the braces should
not be indented! ;-)

 

[Noah Roberts]

Tsk tsk, you're right. That function is WAY too long!

Ok, I was talking more about using goto to get to the end of a void
function so that you can 'return'. Yes functions where long but that
is a bit of another issue. Frankly I don't see any use to this
whatsoever. As far as "structured" programming goes the use of goto is
illegitamate anyway. Sometimes goto is useful, but in this case it is
redundant at best.

 

[Alf P. Steinbach]

* Mike Smith:

I do. (Except, of course, that *EVERYBODY KNOWS* that the braces should
not be indented! ;-)

Well, I don't, or rather, didn't. I did it that way for a period, years
ago, and, even though I found it horrible before that and after that, I
managed to make it seem natural to myself. If anybody asked, and they
did, I just told them "Petzold does it that way", perhaps with an
explanation of how it more accurately represented the parsing level.

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.