Mail Archives: djgpp/1996/08/02/19:59:12
Reply to message 4765644 from KAGEL AT DG1 DOT BLO on 08/02/96 10:06AM
I don't want to start a flame war here, so I would like to state that
the opinions I express here are _my_ opinions and I'm not trying
to criticize any _person_, or ridicule any person's ideas, ok?
There's a difference between debate and flaming. :)
------------------------------------------------
> void SetMCGA(void);
> void SetText(void);
> void Cls(unsigned char);
> void Putpixel(int, int, unsigned char);
> void TestPutpixel(void);
>
>Hey don't beat the guy up on style S**T. There is NOTHING wrong with his
>declarations or his indentation style. I personnally prefer his explicit
>declarations with parameter names. Indeed so did K&R in "The C Programming
>Language, Second Edition" the use explicit prototype declarations for many
code
>samples and point out that the parameter names are optional in the "C"
>standard. I think that the parameter names enhance documentation value and,
as>everyone on the list for any length of time knows I will pile my soap boxes
>higher than Babel to promote better documented code.
Sorry - I forgot about the 'style wars'. :) But the most basic reason for
_not_ including parameter names in the function declarations is that
the scope of the names is limited to the declaration itself; i.e., the
function itself doesn't have to use the same name(s) at all. Thus
the possibility for confusion is created.
I admit to being of two minds about the issue myself - one way
produces better documented code at the expense of more
possibility for confusion, and the other is safe but less self-
explanatory.
>As far as LANDMARK's indentation style, hey that's been my style for over ten
>years! But seriously, it is the style promoted in all of the sample code in
>K&R, do not pummel the newbie for emulating the greats! (Meaning Brian and
>Dennis not me.) He is lining up his closing braces, with the matching opening
>statement, HE JUST FORGOT ONE and as a newbie was just as likely to miss this
>with any other indentation/brace position style!
I dispute that highly and have never understood how putting the opening
brace on the end of the same line helps clarity or readability in any way.
If you simply make sure to line your braces up at the same level of
indentation and use a consistent system of indentation throughout your
program, debugging a missing brace is trivial. But when I looked at the
TestPutpixel function that was posted, I literally had to count braces in
order to determine which one was missing. This does not sound like
good style to me.
And as for the newbie error, I was not criticizing, but simply attempting
to correct his mistake, since he apparently didn't see it himself.
Would you rather I simply not comment and force him to keep making
the mistake until he finally found it? I recommended my style of
indentation because IMHO it aids in finding exactly that sort of error.
Also, one thing I have sometimes foundproblematic with gcc (and
in fact every compiler I've tried) is that it really isn't very helpful
when you do in fact leave off a brace or other closing punctuation.
I've done this in large programs, and all I usually see is a 'syntax
error after so-and-so character' (which only seldom is the actual
location of the error), followed by a huge dump of errors caused
by subsequent code being misinterpreted. There really should be
some way for gcc to check and simply state something like this:
foo.c: 350: Block appears to be missing closing '<mark>'
foo.c: 296: Probable start of block here.
Comments as to feasability/potential problems? I'm not in a
position to try to actually create such a beastie, but maybe in
the future...
>I hereby declare "Be Nice to Newbies Day", please!
Admittedly I may have been a bit rough, but I did apologize to him. :)
John
- Raw text -