The world's evilest code formatting style

[Phlip]

For the record (so you may laugh or not) I write code like this:

void foo(int bar)
{
for (int i = 0; i < bar; i++)
{
std::cout << "Nelly the elephant ";
std::cout << "makes great apple pie\n";

Eeeewe! You said std:: _twice_!!!

Duplicated code!! Shun! Shun!!!

 

[Alex Buell]

Eeeewe! You said std:: _twice_!!!

Duplicated code!! Shun! Shun!!!

T'was an example.

 

[Noah Roberts]

Full disclosure: virtually all of my code is templated which means I ditched
the distinction of header and implementation files since implementation
files would almost always be empty anyway (given that my compiler does not
suport export). Consequently, I also ditched declaration vs. definition,
i.e., everything is defined in place so that the class::method() form just
does not occur in the code. I never found a drawback with regard to
grepability or readability of code.

But you may very well find a drawback in compile dependencies. Change
one class...have to compile everything...not fun. When at all possible
implementation should be hidden from the clients if for no other reason
than this one. Large projects can get really burdenful to work on when
a simple change to the private implementation of a class requires you
to do a complete rebuild; it also discourages testing correctly because
a person has to wait 5 minutes for a full compile for every single
minor change - and idealy they are testing any time they make even a
minor change.

Idealy changing a class's insides should do no more than require a
compile of the class that was altered and a relink. Templates are a
bitch in this regard but there is no reason to create those
dependencies when not required.

 

[Phlip]

T'was an example.

Note I didn't bust on your lovely style ;-)

(BTW the other inside joke is that std:: is structure, not behavior, so its
duplication is less revelant to design.)

 

[John L Fjellstad]

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.

I take it you think Kernighan, Ritchie and Stroustrup are dumbasses,
since that's the style they have in their books.
Although K&R is more like

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


Or to put in Linus Thorvalds words (from the CodingStyle document for
the Linux kernel):

Chapter 3: Placing Braces

The other issue that always comes up in C styling is the placement of
braces. Unlike the indent size, there are few technical reasons to
choose one placement strategy over the other, but the preferred way, as
shown to us by the prophets Kernighan and Ritchie, is to put the opening
brace last on the line, and put the closing brace first, thusly:

if (x is true) {
we do y
}

However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
body of function
}

Heretic people all over the world have claimed that this inconsistency
is ... well ... inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right. Besides, functions are
special anyway (you can't nest them in C).

Note that the closing brace is empty on a line of its own, _except_ in
the cases where it is followed by a continuation of the same statement,
ie a "while" in a do-statement or an "else" in an if-statement, like
this:

do {
body of do-loop
} while (condition);

and

if (x == y) {
..
} else if (x > y) {
...
} else {
....
}

Rationale: K&R.

Also, note that this brace-placement also minimizes the number of empty
(or almost empty) lines, without any loss of readability. Thus, as the
supply of new-lines on your screen is not a renewable resource (think
25-line terminal screens here), you have more empty lines to put
comments on.

 

[Phlip]

The other issue that always comes up in C styling is the placement of
braces. Unlike the indent size, there are few technical reasons to
choose one placement strategy over the other, but the preferred way, as
shown to us by the prophets Kernighan and Ritchie, is to put the opening
brace last on the line, and put the closing brace first, thusly:

if (x is true) {
we do y
}

That's not "preferred" - it's an artifact of writing a book. The "rationale"
is only to save vertical space and make room for your wondrous prose.

 

[Axter]

I also think it's a waste to put white spaces in code for one line of
code, just because you think there should be white spaces.
IMHO, if you cann't read the following line of code without white
spaces, then maybe you should be doing something else beside
programming in C++.
inline T* operator[](size_t i) {return (m_data + (m_col*i));}

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 find the above line of code to be extreemely simplistic, and the fact
that you're indicating that you and all the programmers you know would
need to do a double or triple take to read above line of code,
indicates that you have poor code reading skills and all the
programmers you assoicated yourself with also have poor code reading
skills.

I recommend you spend more time improving your code reading skills, and
less time complaining about other programmer's code format.

 

[Phlip]

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 find the above line of code to be extreemely simplistic

Please count how many seconds you take to spot this bug:

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

Be honest - did you see it yet?

I recommend you spend more time improving your code reading skills, and
less time complaining about other programmer's code format.

We all wish we were as smart as you. We are not, so we take a little time to
properly format, and this saves us hours of hard labor when reading code. We
are also considerate of our colleagues, who are clearly not as smart as us.

And all code should be read-write, not just write-only. That is the path
towards BASIC.

 

[Noah Roberts]

I also think it's a waste to put white spaces in code for one line of
code, just because you think there should be white spaces.
IMHO, if you cann't read the following line of code without white
spaces, then maybe you should be doing something else beside
programming in C++.
inline T* operator[](size_t i) {return (m_data + (m_col*i));}

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 find the above line of code to be extreemely simplistic, and the fact
that you're indicating that you and all the programmers you know would
need to do a double or triple take to read above line of code,
indicates that you have poor code reading skills and all the
programmers you assoicated yourself with also have poor code reading
skills.

I recommend you spend more time improving your code reading skills, and
less time complaining about other programmer's code format.

Heheheh...ok dude. I don't know how you could possibly function with
that attitude but whatever; maybe you spend most time working alone.
I'm just glad MOST people learn how to write readable code
eventually...you obviously never did. Lucky for me, and the rest of us
coders with "poor reading skills", the average coder takes more pride
in their work and in making sure they can be understood. Otherwise we
would be spending more time pulling our hair out because some dipshit
decides to do the C++ equivilant of mile long runon sentances than in
actually accomplishing anything.

See, some of us like to retain job security by being good at what we do
and continuously improving...not by being the only person that can read
our convoluted spaghetti code. People like you bring productivity to a
standstill.

The more you speak the more I'm convinced you must be one of the worst
programmers in the field.

 

[Noah Roberts]

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 find the above line of code to be extreemely simplistic

Please count how many seconds you take to spot this bug:

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

Be honest - did you see it yet?

Nice...looked at it twice and said, "I don't see no bug," did a direct
char for char comparison of the two and found it. Yes, the lack of
spaces very nicely obscures that bug. Certainly difficult to find for
anyone used to looking at properly formatted code (being ANY format
that contains whitespace where it isn't REQUIRED by the language at
this point). I bet it would take hours to find that in the
trenches...I have lots of experience with such bugs and they where in
formatted code.

We all wish we were as smart as you. We are not, so we take a little time to
properly format, and this saves us hours of hard labor when reading code. We
are also considerate of our colleagues, who are clearly not as smart as us.

Hear hear.

 

[Phlip]

Nice...looked at it twice and said, "I don't see no bug,"

The trick was screwing with low-density punctuation, not high-density
letters.

did a direct
char for char comparison of the two and found it. Yes, the lack of
spaces very nicely obscures that bug.

You had something to compare with.

I have found myself these days not even bothering to tab, and I just
frequently run astyle, configured to our corporate style guide.

 

[Duane Hebert]

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 find the above line of code to be extreemely simplistic

Please count how many seconds you take to spot this bug:

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

Be honest - did you see it yet?

Had a test for a job interview once and most of the questions had
something like:

class spoo {spoo(); private void somefunction();int doh; ...};

Didn't find it that amusing.

 

[Axter]

Axter wrote:

I also think it's a waste to put white spaces in code for one line of
code, just because you think there should be white spaces.
IMHO, if you cann't read the following line of code without white
spaces, then maybe you should be doing something else beside
programming in C++.
inline T* operator[](size_t i) {return (m_data + (m_col*i));}

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 find the above line of code to be extreemely simplistic, and the fact
that you're indicating that you and all the programmers you know would
need to do a double or triple take to read above line of code,
indicates that you have poor code reading skills and all the
programmers you assoicated yourself with also have poor code reading
skills.

I recommend you spend more time improving your code reading skills, and
less time complaining about other programmer's code format.

Heheheh...ok dude. I don't know how you could possibly function with
that attitude but whatever; maybe you spend most time working alone.
I'm just glad MOST people learn how to write readable code
eventually...you obviously never did. Lucky for me, and the rest of us
coders with "poor reading skills", the average coder takes more pride
in their work and in making sure they can be understood. Otherwise we
would be spending more time pulling our hair out because some dipshit
decides to do the C++ equivilant of mile long runon sentances than in
actually accomplishing anything.

See, some of us like to retain job security by being good at what we do
and continuously improving...not by being the only person that can read
our convoluted spaghetti code. People like you bring productivity to a
standstill.

The more you speak the more I'm convinced you must be one of the worst
programmers in the field.

You could be right.

I'm the second highest ranking Expert in the C++ topic area for the
Experts-Exchange:
http://www.experts-exchange.com/Cplusplus
The Experts-Exchange is a well know controlled forum. (User name Axter)

I regularly post C++ answers for questioners in CodeGuru, CodeProject,
and MSDN.vc.

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

And I've been programming in C++ for over 10 years, and programming in
C for close to 20 years.

I also have articles posted in CodeGuru, CodeProject, and other's that
I don't even remember any more.

But you could still be right, and I could be the worst programmer in
the field.
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.

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.

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

 

[Ian Collins]

I think it's a waste to put braces on the next line when you only have
one line of code.

Waste of what? Photons?

 

[Phlip]

I'm the second highest ranking Expert in the C++ topic area for the
Experts-Exchange:
http://www.experts-exchange.com/Cplusplus
The Experts-Exchange is a well know controlled forum. (User name Axter)

I used to hit that high on such tests. (Then the C++ committees added those
recent extensions to everything

Such tests cannot rate teamwork. Of course they can rate code obfuscation.
And they can't rate refactoring to clean stuff up because the results would
be subjective.

And team members typically don't brag so much, either. ;-)

 

[Nobody]

I think it's a waste to put braces on the next line when you only have

one line of code.

Thats just dumb. You do know the compiler strips out whitespace don't you?
Whitespace is there to make the code readable. I could put 50x the
whitespace you put, and although my code will be more
readable, they will compile the same.

Although, I do hate it when people OVER whitespace as in:

Whatever(param1,
param2,
param3,
param4);

Although I suppose that does make things more readable. I will continue
parameters on the 2nd line if they go to far on one line... but I'll
generally let it run up to column 100 - 120 before I put it on a 2nd line.

 

[Nobody]

I recommend you spend more time improving your code reading skills, and
less time complaining about other programmer's code format.

Thats just dumb... I shouldn't need to "read" your code or spend a few
minutes analyzing what it does... I should be able to easily tell what it
does just by looking at it or having it clearly commented.

 

[Nobody]

I find the above line of code to be extreemely simplistic, and the fact

that you're indicating that you and all the programmers you know would
need to do a double or triple take to read above line of code,
indicates that you have poor code reading skills and all the
programmers you assoicated yourself with also have poor code reading
skills.

Oh, and by the way, not only does code like that make it difficult to read,
it makes it difficult to step through it with a debugger.

 

[Noah Roberts]

Thats just dumb... I shouldn't need to "read" your code or spend a few
minutes analyzing what it does... I should be able to easily tell what it
does just by looking at it or having it clearly commented.

Personally I feel comments should be rarely required. Your code should
be self documenting and easily understood.

Granted, certain special cases make that difficult and the concepts
will need to be explained...but really, it is rather rare that you get
to do anything 'difficult' with code so most of the time comments
should be redundant.

 

[Ian Collins]

Thats just dumb... I shouldn't need to "read" your code or spend a few
minutes analyzing what it does... I should be able to easily tell what it
does just by looking at it or having it clearly commented.

Better yet, just read thought the unit tests.

By the way, it's generally considered bad form to remove attributions
from replies.