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!!!
Jun 4 '06
93  3786 
Ron House wrote: 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.
This is precicely what I do with one liners (except the braces go
either on the first column or have one indent and the code another).
I've never seen any case where this actually lowers readability.
Ron House wrote: Only if you are in the habit of inconsistency in using braces.
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.
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
"Jim Langston" <ta*******@rocketmail.com> wrote in message
news:Iw***************@fe03.lga... "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.
Oh, I forgot about something else this 2nd person does. He puts functions
in .h files. So he only has one .cpp file and everything else is included
in .h including functions, etc... Very bad, but I couldn't convince him of
that.
In article <_G******************@newssvr11.news.prodigy.com >,
Phlip <ph******@yahoo.com> 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.
In the original for the above code snippet, was there white space
at the beginning of each line, or were the lines (particularly
the one starting with "inherits") unindented?
If the latter, it is probably a continuation of an old C
formatting style wherein the definitions of each function
had the function name always the beginning of a line. This
makes it easy to find the function definition (as opposed
to function calls) with a text editor search.
Such formatting is obsolesced by modern tools, but was useful
in its day, and I used it myself (when working in C) up to about
five years ago.
Steve
Steve Pope wrote: If the latter, it is probably a continuation of an old C
formatting style wherein the definitions of each function
had the function name always the beginning of a line. This
makes it easy to find the function definition (as opposed
to function calls) with a text editor search.
My favorite:
void
kozmik()
{
}
That is beyond reproach. It puts the most important thing in the first
column, and the lessor thing.
Now replace 'void' with some huge type from hell, and that style gets even
better.
Such formatting is obsolesced by modern tools, but was useful
in its day, and I used it myself (when working in C) up to about
five years ago.
void
Foo::kozmik()
{
}
But the code I got that sample from was post-modern. It used Boost::Spirit,
and it used multiply nested namespaces. I'm beginning to think most of those
things are nothing but cures in search of diseases...
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Phlip wrote: Steve Pope wrote:
If the latter, it is probably a continuation of an old C
formatting style wherein the definitions of each function
had the function name always the beginning of a line. This
makes it easy to find the function definition (as opposed
to function calls) with a text editor search.
My favorite:
void
kozmik()
{
}
That is beyond reproach. It puts the most important thing in the first
column, and the lessor thing.
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.
<Vkwgg.178431$bm6.26661@fed1read04>, Nobody <no****@cox.net> wrote: ... 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.
Certainly is. It should be:
void Whatever()
{
for (int i = 0; i < 100; i++) {
printf("whatever\n");
}
}
The idea is that to find the left brace for a given right
brace, go upwards until you find a line less indented than
the right brace.
The exception being the braces for the function itself,
which are both un-indented.
(Not that there aren't many other acceptable ways of
doing it...)
Steve
"Phlip" <ph******@yahoo.com> writes: 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.
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?
--
John L. Fjellstad
web: http://www.fjellstad.org/ Quis custodiet ipsos custodes
Replace YEAR with current four digit year
On Sun, 04 Jun 2006 22:25:43 -0700, Noah Roberts wrote: How about this:
void f()
{
if (preconfail)
goto end;
....
end:
return;
}
Yes, I in fact ran into that in the REAL world.
Well, everyone knows that structured code should only have one return
statement. If you have to use gotos to make sure you have structured
code, that's a sacrifice you'll just have to make.
"Steve Pope" <sp*****@speedymail.org> wrote in message
news:e6**********@blue.rahul.net... <Vkwgg.178431$bm6.26661@fed1read04>, Nobody <no****@cox.net> wrote:
... 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.
Certainly is. It should be:
void Whatever()
{
for (int i = 0; i < 100; i++) {
printf("whatever\n");
}
}
The idea is that to find the left brace for a given right
brace, go upwards until you find a line less indented than
the right brace.
The exception being the braces for the function itself,
which are both un-indented.
(Not that there aren't many other acceptable ways of
doing it...)
Steve
Thats even stupider... not only are you being inconsistent in your use of
braces... but your comment of "look at the indents to find the matching
brace" smells of .... well... lets be nice... but thats dumb... why would
you look at indents to match a brace when you could look at the MATCHING GOD
DAMN BRACE?!?!?!
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");
}
Have a nice day you stinkin' right bracer! :)
Phlip wrote: 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
Aint you one of the guys always telling everyone how O.T. they are...
:-)
regards
Andy Little
"Noah Roberts" wrote: 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
Noah Roberts wrote: 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 http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
John L Fjellstad wrote: 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.
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?
On a computer screen, a little more vertical space, and {} in at least the
same column, make things a little more readable.
Pavel Vozenilek wrote: 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.
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.
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
John L Fjellstad skrev: "Phlip" <ph******@yahoo.com> writes:
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.
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
Axter wrote: 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.
On Sun, 4 Jun 2006 00:54:24 -0700, "Nobody" <no****@cox.net> 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.
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?
On Sun, 04 Jun 2006 07:09:46 GMT, "Phlip" <ph******@yahoo.com> wrote: 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.
JustBoo wrote: On Sun, 04 Jun 2006 07:09:46 GMT, "Phlip" <ph******@yahoo.com> wrote:
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.
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.
"Phlip" <ph******@yahoo.com> writes: John L Fjellstad wrote:
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.
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?
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
--
John L. Fjellstad
web: http://www.fjellstad.org/ Quis custodiet ipsos custodes
Replace YEAR with current four digit year
JustBoo <Ju*****@boowho.com> wrote: On Sun, 4 Jun 2006 00:54:24 -0700, "Nobody" <no****@cox.net> 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.
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_f...l#layout-style
I do not believe that Dr. Stroustrup is "dumb beyond dumb" either.
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
John L Fjellstad wrote: 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/
On a modern computer screen...
--
Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
JustBoo wrote: On Sun, 4 Jun 2006 00:54:24 -0700, "Nobody" <no****@cox.net> 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.
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.
Axter wrote:
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
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. 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
Ron House wrote: 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! ;-)
--
Mike Smith
Phlip wrote: Noah Roberts wrote:
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!
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.
* Mike Smith: Ron House wrote: 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! ;-)
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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Nobody wrote: 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."
Alf P. Steinbach wrote: 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...5kempf&pgno=5).
Cheers! --M
Noah Roberts <ro**********@gmail.com> wrote:
JustBoo wrote: On Sun, 4 Jun 2006 00:54:24 -0700, "Nobody" <no****@cox.net> 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.
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).
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
Marcus Kwok wrote: 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.
On 5 Jun 2006 08:38:48 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote: You do relaize that style is called the Kernighan and Ritchie (K&R)
Style right?
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
JustBoo wrote: On 5 Jun 2006 08:38:48 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote:
You do relaize that style is called the Kernighan and Ritchie (K&R)
Style right?
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.
I'll just say that is quite a leap and leave it at that. You're way
too invested in this silly issue.
On 5 Jun 2006 14:48:05 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote: JustBoo wrote: On 5 Jun 2006 08:38:48 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote:
>> You do relaize that style is called the Kernighan and Ritchie (K&R)
>> Style right?
>
>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.
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
Phlip wrote: Ron House wrote:
Only if you are in the habit of inconsistency in using braces.
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 ho***@usq.edu.au http://www.sci.usq.edu.au/staff/house
Ethics website: http://www.sci.usq.edu.au/staff/house/goodness
Nobody wrote: "Steve Pope" <sp*****@speedymail.org> wrote in message
news:e6**********@blue.rahul.net...
<Vkwgg.178431$bm6.26661@fed1read04>, Nobody <no****@cox.net> wrote:
... 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.
...
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.
--
Ron House ho***@usq.edu.au http://www.sci.usq.edu.au/staff/house
Ethics website: http://www.sci.usq.edu.au/staff/house/goodness
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;
%>
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 {
}
--
Frederick Gotham
Frederick Gotham wrote: 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.
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.
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. This thread has been closed and replies have been disabled. Please start a new discussion. |
