The world's evilest code formatting style

[Phlip]

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.

Now that's not evil just because it's so contrary to common styles and hence
hard to read. It's totally evil when it makes Home::inherits impossible to
search for. Searching, for big projects, is kind'a important!

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

 

[Noah Roberts]

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

Yes.

http://code.axter.com/dynamic_2d_array.h

Google groups is likely to do wonders here...all of the following is on
4 concurrent lines:

dynamic_2d_array(size_t row, size_t col):m_row(row),m_col(col),
m_data((row!=0&&col!=0)?new T[row*col]:NULL){}

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

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

}

Guess he didn't want to waste any space or enter characters.

 

[Nobody]

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.

 

[Phlip]

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

void Whatever() {

Oh, my. I was this -><- close to putting in a disclaimer "don't bring up
braces", but I figured that nobody ... would.

Everyone complains about braces, and once you are over it, you are over it,
and you can read, edit, and refactor, regardless of whatever silly bracing
convention is used.

I suppose putting most (but not all) braces in the first column might be an
exception there...

Noah Roberts cited:

dynamic_2d_array(size_t row, size_t col):m_row(row),m_col(col),
m_data((row!=0&&col!=0)?new T[row*col]:NULL){}

Now now - you may as well bust on Dinkumware's old STL style. That gets
worse when your remote colleague writes unmaintainable BASIC and crams lines
full of run-on statements with 2-letter variables "because I can get more on
the screen like that".

Let's narrow the question to a style that is A> hallowable in a style guide,
and B> a failed attempt at clarity, not a successful attempt at obscurity.

 

[Kai-Uwe Bux]

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.

Dear top-poster,

care to provide a reason ...

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.

.... instead of jumping to insults right away?


[mindlessly copied original post redacted]


Best

Kai-Uwe Bux

 

[Phlip]

care to provide a reason ...

Because our last best hope for clarity among nested blocks is the ability to
see { in the same column as }.

(The goal "don't write too many lines in a block" also applies. And some
namespace situations make that impossible, too...)

[mindlessly copied original post redacted]

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

 

[Kai-Uwe Bux]

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.

Now that's not evil just because it's so contrary to common styles and
hence hard to read. It's totally evil when it makes Home::inherits
impossible to search for. Searching, for big projects, is kind'a
important!

I see the importance of grepability for code. However, there will be many
contexts where it does not read Home::inherits but just inherits anyway.

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.


Best

Kai-Uwe Bux

 

[Kai-Uwe Bux]

Because our last best hope for clarity among nested blocks is the ability
to see { in the same column as }.

I guess whether that poses a problem depends heavily on what you are used
to. I never found any difficulty with right-bracing in regard of clarity.
But then again, my blocks are not that deeply nested anyway.

(The goal "don't write too many lines in a block" also applies. And some
namespace situations make that impossible, too...)

[mindlessly copied original post redacted]

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

Thanks. Will do.


Best

Kai-Uwe Bux

 

[Rolf Magnus]

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

Yes.

http://code.axter.com/dynamic_2d_array.h

Google groups is likely to do wonders here...all of the following is on
4 concurrent lines:

dynamic_2d_array(size_t row, size_t col):m_row(row),m_col(col),
m_data((row!=0&&col!=0)?new T[row*col]:NULL){}

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

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

}

Guess he didn't want to waste any space or enter characters.

Reminds me of C64 basic code, where people used to write code in this style.
You could even leave out spaces between keywords and identifiers. The
common loop started like FORI=0TO10

 

[Noah Roberts]

I guess whether that poses a problem depends heavily on what you are used
to. I never found any difficulty with right-bracing in regard of clarity.
But then again, my blocks are not that deeply nested anyway.

I don't see it as a "problem" but braces on the next line are more
immediately readable to me.

Really, that is a small issue. The real issue is that whitespace
should at least be used somewhere and code should be written to be as
readable as possible without going really insain on the idea.

 

[Jim Langston]

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.

Now that's not evil just because it's so contrary to common styles and
hence hard to read. It's totally evil when it makes Home::inherits
impossible to search for. Searching, for big projects, is kind'a
important!

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

I have two, one easy to fix.

Some code I work with has no indentation whatsoever, everything is left
justified. This is easy enough to fix in my IDE though, I just select
everthing and hit a few keys to auto indent. Takes me a few seconds.

The second is code someone has me work with sometimes. Not only does it not
have any indents, it has absolutely no whitespace, and many statements on
one line. This takes a while to format so I can read it.

 

[Axter]

I don't see it as a "problem" but braces on the next line are more
immediately readable to me.

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

Really, that is a small issue. The real issue is that whitespace
should at least be used somewhere and code should be written to be as
readable as possible without going really insain on the idea.

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 like to be able to read as much as my code in one page as possible,
and putting useless extra lines of code, makes that harder to do.

IMHO, throughing useless whitespaces and useless extra lines of code in
your code, makes it harder to read from top to bottom, and it can be
more of a destraction, then something that adds clarrity.

 

[Axter]

I see the importance of grepability for code. However, there will be many
contexts where it does not read Home::inherits but just inherits anyway.

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.

I totally agree with this method.
And if you notice, boost also does this a lot in it's implementation.

 

[Axter]

I have two, one easy to fix.

Some code I work with has no indentation whatsoever, everything is left
justified. This is easy enough to fix in my IDE though, I just select
everthing and hit a few keys to auto indent. Takes me a few seconds.

I think what is even more evil is having the code indentation mixed
improperly.

void foo()
{
for(..)
{
while(..)
{
}
}
}

IMHO, this is even more evil then not having any indentation, because
in a large block of code, any one reading this, might not imediately
realize the mis-allignment and read the code improperly.
Although this can be easily fixed with an IDE, the damage migh already
have been done, if you had to waste extra time tracking down code in
the wrong section.

 

[Azumanga]

I think what is even more evil is having the code indentation mixed
improperly.

void foo()
{
for(..)
{
while(..)
{
}
}
}

IMHO, this is even more evil then not having any indentation, because
in a large block of code, any one reading this, might not imediately
realize the mis-allignment and read the code improperly.

If I was working on the C++0x standard, I would require the compiler
rejects code like this Don't just use indentation for marking blocks
like Python, but require the indentation matches the blocks.

 

[Phlip]

If I was working on the C++0x standard, I would require the compiler
rejects code like this Don't just use indentation for marking blocks
like Python, but require the indentation matches the blocks.

Two reasons this thread is beyond stupid: astyle & indent.

;-)

(Before those knees jerk, I started the thread so I'm allowed to say
that...)

The second is code someone has me work with sometimes. Not only does it
not
have any indents, it has absolutely no whitespace, and many statements on
one line. This takes a while to format so I can read it.

I tried to break such lines up with astyle but can't find the option. Yet I
posit that digging up such a feature is more fun than manually reformatting.

 

[Phlip]

I tried to break such lines up with astyle but can't find the option. Yet

I posit that digging up such a feature is more fun than manually
reformatting.

Oh duh, it's --break-blocks. Someone had an obsolete man page...

 

[kwikius]

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.

And what sort of bracer are you, a droopy bracer? Every droopy bracer I
met is a Whacko, Barking, Bonkers, Raving Buffoon!

I call them drooly slobbery bracers and I tie their shoelaces together
so they fall over.

Then they look really stupid! Ha ha!

 

[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 don't know if I would be amazed or disgusted.

Worse than that is the following one liner right above the above quoted
code:

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. That is 148 characters, all on one line, not including
the indentation before the first character or the brace that
immediately follows.

 

[Alex Buell]

And what sort of bracer are you, a droopy bracer? Every droopy bracer
I met is a Whacko, Barking, Bonkers, Raving Buffoon!

What does their code looks like, just out of interest?

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