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? ;-)
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 93  3785 
Phlip wrote: 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.
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" <ph******@yahoo.com> wrote in message
news:_G******************@newssvr11.news.prodigy.c om... 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? ;-)
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Nobody wrote: 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.
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Nobody wrote: 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
Kai-Uwe Bux wrote: void Whatever() {
for (int i = 0; i < 100; i++) {
printf("whatever\n");
}
}
Thats just dumb beyond dumb.
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". ;-)
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Phlip wrote: 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
Phlip wrote: Kai-Uwe Bux wrote:
void Whatever() {
for (int i = 0; i < 100; i++) {
printf("whatever\n");
}
}
Thats just dumb beyond dumb. 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 }.
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
Noah Roberts wrote:
Phlip wrote:
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
Kai-Uwe Bux wrote: Phlip wrote:
Kai-Uwe Bux wrote:
void Whatever() {
for (int i = 0; i < 100; i++) {
printf("whatever\n");
}
}
Thats just dumb beyond dumb.
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 }.
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.
"Phlip" <ph******@yahoo.com> wrote in message
news:_G******************@newssvr11.news.prodigy.c om... 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.
Noah Roberts wrote: Kai-Uwe Bux wrote: Phlip wrote:
Kai-Uwe Bux wrote:
>> void Whatever() {
>> for (int i = 0; i < 100; i++) {
>> printf("whatever\n");
>> }
>> }
>>
>> Thats just dumb beyond dumb.
> 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 }.
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.
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.
Kai-Uwe Bux wrote: Phlip wrote:
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.
I totally agree with this method.
And if you notice, boost also does this a lot in it's implementation.
Jim Langston wrote: "Phlip" <ph******@yahoo.com> wrote in message
news:_G******************@newssvr11.news.prodigy.c om... 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.
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.
Axter wrote: 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.
Azumanga wrote: 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...)
Jim Langston wrote:
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 http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
> 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...
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Nobody wrote: 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!
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 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.
On 4 Jun 2006 07:58:48 -0700, I waved a wand and this message magically
appeared from kwikius: 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";
}
}
-- http://www.munted.org.uk
Take a nap, it saves lives.
Alex Buell wrote: 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!!!
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
On Sun, 04 Jun 2006 17:21:48 GMT, I waved a wand and this message
magically appeared from Phlip: std::cout << "Nelly the elephant ";
std::cout << "makes great apple pie\n";
Eeeewe! You said std:: _twice_!!!
Duplicated code!! Shun! Shun!!!
T'was an example.
-- http://www.munted.org.uk
Take a nap, it saves lives.
Kai-Uwe Bux wrote: 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.
Alex Buell wrote: > std::cout << "Nelly the elephant ";
> std::cout << "makes great apple pie\n";
Eeeewe! You said std:: _twice_!!!
Duplicated code!! Shun! Shun!!!
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.)
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
"Nobody" <no****@cox.net> writes: 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.
--
John L. Fjellstad
web: http://www.fjellstad.org/ Quis custodiet ipsos custodes
Replace YEAR with current four digit year
Noah Roberts wrote: 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.
John L Fjellstad wrote: 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.
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Axter wrote: 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.
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Axter wrote: Noah Roberts wrote: 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.
Phlip wrote: Axter wrote:
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.
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.
Hear hear.
Noah Roberts wrote: 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.
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
"Phlip" <ph******@yahoo.com> wrote in message
news:92******************@newssvr27.news.prodigy.n et... Axter wrote:
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.
Noah Roberts wrote: Axter wrote: Noah Roberts wrote: 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.
Axter wrote: Noah Roberts wrote:
Kai-Uwe Bux wrote:
Phlip wrote:
Kai-Uwe Bux wrote:
>>void Whatever() {
>> for (int i = 0; i < 100; i++) {
>> printf("whatever\n");
>> }
>>}
>>
>>Thats just dumb beyond dumb.
>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 }.
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.
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?
--
Ian Collins.
Axter wrote: 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. ;-)
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
> 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. 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.
> 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.
Nobody wrote: 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.
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.
Nobody wrote: 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.
Better yet, just read thought the unit tests.
By the way, it's generally considered bad form to remove attributions
from replies.
--
Ian Collins.
> coders with "poor reading skills", the average coder takes more pride in their work and in making sure they can be understood. Otherwise we
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...
"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11********************@g10g2000cwb.googlegrou ps.com...
Nobody wrote: > 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.
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.
True... I don't comment every line, and am definitely guilty of using
useless comments as a code formatting crutch... even in my personal comments
I have code like
// clear the menu flags
pDLL->bMenuFlag = FALSE;
// do something else
.....
While everybody in this thread will think thats an insanely dumb comment
(and it is)... it allows me to format the code to my liking.
Axter wrote: 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)
Oh jeesh...here we go again.
Ok, Mr. Expert...you have no excuse for sending people to that hackery
you call code in dynamic_2d_array then. I then have to assume you are
doing it to purposfully mislead those that are trying to learn C++.
'Cause that crap is crap. No two ways about it. It's riddled with bad
design, bad practice, and basic bugs. These numerous problems have
been pointed out to you several times and you've had plenty of time to
fix it (in fact you had time to make it worse) yet you continue to use
it as an example and hand it off to beginners trying to learn.
Frankly, the fact that a bunch of the poor suckers actually think
you've helped them is sad to say the least.
You know, I have also been published many times. My articles have been
translated to numerous languages including Chinese. But that is
completely irrelivant to whether I know wtf I'm talking about and it is
no different with you. Frankly, it doesn't take much to be published
anymore...especially on some free help website.
How is someone supposed to take you seriously when you call code like
your d2 array 'examples'? I've looked at your smart pointer a small
amount and it didn't show the basic flaws your d2 array does...I didn't
review it all but it definately isn't something I could chew up and
spit out like your d2 array...but you don't seem to be handing that one
out saying, "Here, this is how it is done." What you _are_ handing out
is just garbage and I for one hate seeing it being used for teaching
beginners....fix it already....stop giving out bad advice.
Ian Collins wrote: Nobody wrote: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.
Better yet, just read thought the unit tests.
Unit testing and TDD are not something I was taught in school or have
been mentored into. I have grabbed some books on the subject and am
delighted at how useful I am finding it. I have been thinking of
spending the 2 grand on one of the object mentor courses...especially
if I can get my employer to help. Anyone been to one?
Noah Roberts wrote: Ian Collins wrote:
Nobody wrote:
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.
Better yet, just read thought the unit tests.
Unit testing and TDD are not something I was taught in school or have
been mentored into. I have grabbed some books on the subject and am
delighted at how useful I am finding it. I have been thinking of
spending the 2 grand on one of the object mentor courses...especially
if I can get my employer to help. Anyone been to one?
Good to see someone with an open mind.
I don't have any experience with Object Mentor, but they do have a good
reputation.
Try asking on one of the XP or TDD yahoo lists.
Good luck,
--
Ian Collins.
Ian Collins wrote: Noah Roberts wrote: Ian Collins wrote:
Nobody wrote:
>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.
Better yet, just read thought the unit tests.
Unit testing and TDD are not something I was taught in school or have
been mentored into. I have grabbed some books on the subject and am
delighted at how useful I am finding it. I have been thinking of
spending the 2 grand on one of the object mentor courses...especially
if I can get my employer to help. Anyone been to one?
Good to see someone with an open mind
Yes well, I learned long ago that a closed mind is malfunctional and
try to remain as open as I can. Besides, it's hard to argue with
success.
I don't have any experience with Object Mentor, but they do have a good
reputation.
They certainly write good books.
Actually, I was conversing with them on Friday before I went home for
the weekend. If I could get 10 people in my area interested I could
probably get them up here and in a classroom. I'm in Lacey, WA. I get
the 10 I get my ride for free but would likely end up spending it on
the venue.
I'm interested in their TDD course that includes unit testing and
refactoring. It's 3 days and costs 2 grand. Anyone else interested?
Can't promise anything but if I can get enough people saying they want
to go that will in fact sign up I would be more than happy to continue
trying to get it happening.
Nobody wrote: coders with "poor reading skills", the average coder takes more pride
in their work and in making sure they can be understood. Otherwise we
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.
Let me get this straight. The company rewarded heroism by dismissing the
team and keeping the hero. And now the boss's boss knows his next target.
Your only hope here is to make sure your bosses never learn that code can be
easily shared among programmers, particularily if it has short methods and
extensive unit tests.
Start at the top and work your way to the bottom of this checklist.
http://c2.com/cgi/wiki?JobSecurity
Its not that I write poor code, in fact, I take time to VERY nicely format
and comment code...
Ah, so it has short lines and methods, very little duplication, and eeeeunit
tests?
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Noah Roberts wrote: Unit testing and TDD are not something I was taught in school or have
been mentored into. I have grabbed some books on the subject and am
delighted at how useful I am finding it. I have been thinking of
spending the 2 grand on one of the object mentor courses...especially
if I can get my employer to help. Anyone been to one?
If you are near Southern California I can save you 1 grand. ;-) http://www.zeroplayer.com/cgi-bin/wi...UserInterfaces
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Nobody wrote: // clear the menu flags
pDLL->bMenuFlag = FALSE;
// do something else
Comments suck.
<a beat>
<vbgdrc*>
--
Phlip
* very big grin; duck and run for cover
Phlip wrote: Kai-Uwe Bux wrote:
void Whatever() {
for (int i = 0; i < 100; i++) {
printf("whatever\n");
}
}
Thats just dumb beyond dumb.
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 }.
Only if you are in the habit of inconsistency in using braces.
The source of this style, afaik, was a paper by AJ Sale proposing a
similar style for Pascal. The reason is to align the block structure of
the language's logical structure with the line-oriented layout of a text
document. Each language structure looks like:
starting template
...indented contents...
ending template.
So, your starting template is:
for (...;...;...) {
All of it is compulsory because it is a cookie-cutter template. That
means no 'naked' statements inside loops unprotected by curlies. To take
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. That
matters: too low an information density on a screen or page lowers
comprehension in the same way as too high a density. So people write:
for (int i = 0; i < 100; i++)
printf("whatever\n");
Then they remember they forgot a line, so they insert it:
for (int i = 0; i < 100; i++)
k = 2;
printf("whatever\n");
and then they have a bug. I have used Sale's style, adapted for C and
C++, for decades, taught it to classes, and seen with my own eyes how it
lowers the bug level. It puts a good information density on a page,
aligns block structure with line structure, and allows spotting errors a
line at a time. Any line starting with 'for' and not ending with '{' is
wrong.
--
Ron House ho***@usq.edu.au http://www.sci.usq.edu.au/staff/house This thread has been closed and replies have been disabled. Please start a new discussion. |
