Commenting the source code.

[Daniel Haude]

On 26 Oct 2004 15:23:39 GMT,

Consider the code dealing with opcode mnemonics in an assembler. A jumbo
switch dealing with each mnemonic as a case (by the time you have checked
that it is a valid mnemonic you can also assign it a unique integer value:
its position in the valid mnemonic array) is the most natural approach.

I like to farm out such code to automatically generated files (by flex or
some hand-written utility).

--Daniel

 

[Dan Pop]

On 26 Oct 2004 15:23:39 GMT,


I like to farm out such code to automatically generated files (by flex or
some hand-written utility).

Then, you're no longer implementing the thing in C. And I have yet to
see automatic C code generators that produce human-friendly C code.

Dan

 

[Daniel Haude]

On 27 Oct 2004 15:01:20 GMT,

Then, you're no longer implementing the thing in C. And I have yet to
see automatic C code generators that produce human-friendly C code.

They don't, but that doesn't matter: What matters is that you can rely on
the ugly, automatically-generated, linked-in spaghetti code being
either consistently correct -- or consistently incorrect (which is usually
quite easily fixable).

What the hell. I don't think we need to argue about the pros and cons of
code generators in here, especially as it is off-topic in this thread.

 

[John Bode]

I know that. I just prefer the first way, as when I am reading the
source it "reads" better, to me. You may prefer the second way, and code
it any way you wish. Some people may prefer "x = x+1;", but I like
"++x;" which I read (in my mind) as increment x. YMMV.

Kind of like how declarator syntax causes me to read "int *a;" as "a
is pointer to type int" in my head, even though I know the *correct*
reading is "a is type pointer to int". A subtle difference to some,
maybe, but it's something that continues to irk me, even though it
probably saved me from committing a mistake like

int* a, b;
b = malloc (SIZE * sizeof *b);

that seems to bite a lot of people when they first start using
pointers.

 

[pete]

Hi,

I know that this is off topic.

I don't think that it is.

Do you comment your source code while coding or after coding.

Either or both.
I try to write code so that no commenting is needed,
but I can't always. CBFalconer once suggested that I should comment
a square root function that I had posted here.
My intention while writing it, was that it should be
that kind of good code that didn't need comments,
but my first attempt to explain it was incorrect,
so I commented it.

 

[Dan Pop]

On 27 Oct 2004 15:01:20 GMT,


They don't, but that doesn't matter: What matters is that you can rely on
the ugly, automatically-generated, linked-in spaghetti code being
either consistently correct -- or consistently incorrect (which is usually
quite easily fixable). ^^^^^^^^^^^^^^^^

^^^^^^^^^^^^^^^^^^^

Wishful thinking. When the code is generated by a hand-written
utility you don't even know what went wrong: a bug in the utility or
a bug into the source code processed by the utility. You have to
compare the ugly C code with the source code it came from and try
to figure out what went wrong, which is seldom an easy job: it's
like debugging a C program by examining the assembly output of the
compiler and trying to figure out whether the bug was in the C code
or in the compiler.

What the hell. I don't think we need to argue about the pros and cons of
code generators in here, especially as it is off-topic in this thread.

Guess who introduced them in this thread?

Dan

 

[Dan Pop]

Kind of like how declarator syntax causes me to read "int *a;" as "a
is pointer to type int" in my head, even though I know the *correct*
reading is "a is type pointer to int".

If you get the semantics right, it doesn't matter how you read it in your
head. I'd call it pointer to int, if I needed to give it a name, which I
don't when reading C code. I conceptualise what it is without giving it
any name.

A subtle difference to some,
maybe, but it's something that continues to irk me, even though it
probably saved me from committing a mistake like

int* a, b;
b = malloc (SIZE * sizeof *b);

that seems to bite a lot of people when they first start using
pointers.

It's the people learning C++ directly that are most prone to this mistake.
K&R2 and the C standard use the only sensible style when declaring
pointers, which is not likely to mislead anyone. That is, until some
foolish newbie discovers the following device:

#define INTPTR int *
INTPTR a, b;



Dan