C in Science and Engineering...

[FredK]

Nick Keighley a écrit :

Instead of talking like this have you EVER reflected on
why comments are absent from throw-away software?

Have you ever reflected on why comments are absent from a lot of C
*production* code? Ever read the Linux source? "We don't need no stinkin'
comments, the code is self documenting." is all I can figure. "Real men"
don't need comments.

After 30+ years of programming for a living, I long ago discovered that you
often can't predict the lifetime of code - even what at the time you thought
was "throw away" code. So I comment pretty much every piece of code I
write, since I expect at some random time down the road I'll need to re-use
it or will need to fix it.

Of course, there are good comments and bad comments. Good comments describe
why something is being done /* this loop derives the ... */ as opposed to
describing the obvious /* is j null? */

 

[Nick Keighley]

Have you ever reflected on why comments are absent from a lot of C
*production* code?  Ever read the Linux source?  "We don't need no stinkin'
comments, the code is self documenting." is all I can figure.  "Real men"
don't need comments.

After 30+ years of programming for a living, I long ago discovered that you
often can't predict the lifetime of code - even what at the time you thought
was "throw away" code.  So I comment pretty much every piece of code I
write, since I expect at some random time down the road I'll need to re-use
it or will need to fix it.

Of course, there are good comments and bad comments.  Good comments describe
why something is being done /* this loop derives the ... */ as opposed to
describing the obvious /* is j null? */

the Refactoring people (eg. Fowler) encourage the removal of comments.
The argument being that if you have to comment it then it should have
been a function with a name that matched the comment.

/* this loop derives the snafu context */
while (!snafu_value)
....

should be replaced with

derive_snafu context ();

I'm still thinking about this. I still want major chunks of code to
have comments that indicate what their intent is.

On the other hand I hate those code templates that demand a header
like this

/*
* Name: derive_snafu_context
*
* Arguments: none
*
* Return: none
*/
void derive_snafu context ()
{
}

that sort of stuff drives me mad.

 

[Tim Streater]

the Refactoring people (eg. Fowler) encourage the removal of comments.
The argument being that if you have to comment it then it should have
been a function with a name that matched the comment.

/* this loop derives the snafu context */
while (!snafu_value)
....

should be replaced with

derive_snafu context ();

I'm still thinking about this. I still want major chunks of code to
have comments that indicate what their intent is.

OK, so you move all the code into derive_snafu_context() and then you
comment *that*. What's the benefit?

On the other hand I hate those code templates that demand a header
like this

/*
* Name: derive_snafu_context
*
* Arguments: none
*
* Return: none
*/
void derive_snafu context ()
{
}

that sort of stuff drives me mad.

That's because this sort of template is ugly as sin.

 

[Nick]

For the sorts of things it's good at, Ruby is a particularly expressive
language, and for large categories of problems, I would usually expect that
I could have something working reliably in Ruby in a tiny fraction of the
time it would take me to get something comparable working reliably in C.

There are, of course, tradeoffs. It's not going to execute as quickly as
the C code, for instance.

But if I were doing, say, some kind of dynamic web content, I would take
Ruby over C in nearly all cases. *Nearly* all, mind.

I think I would if I was starting again. Neither were widespread or
mature enough when I started my application. I need to use C or similar
for the core route-planning function (a big "shortest path" calculation)
and ended up developing from what was a configuration language around
this to a full scripting language.

Today I'd use Ruby or Python calling back to C for the clever stuff. It
wouldn't have been half as much fun to write though (is there anything
as much fun as writing a language?).

 

[FredK]

OK, so you move all the code into derive_snafu_context() and then you
comment *that*. What's the benefit?


That's because this sort of template is ugly as sin.

Perhaps ugly, but perhaps informative. Especially when the template has an
*abstract* explaining what a snafu context is and the approach taken to
derive it.

Pull some random Linux source out that you aren't intimately familiar with -
and anything over a half dozen lines tends to be gibberish. So you spend a
few hours analyzing uncommented logic with "clever" but meaningless routine
names and even less informative variable names. When the programmer could
have spent a few minutes explaining it - heck, even explaining how clever
his naming is.

I comment for myself, knowing that after time passes - even I need to
re-remember why I did what I did.

 

[jacob navia]

FredK a écrit :

Pull some random Linux source out that you aren't intimately familiar with -
and anything over a half dozen lines tends to be gibberish. So you spend a
few hours analyzing uncommented logic with "clever" but meaningless routine
names and even less informative variable names. When the programmer could
have spent a few minutes explaining it - heck, even explaining how clever
his naming is.

The only commùents I find in the gnu source code is the FSF copyright
notice at the beginning of each file. This is a constant problem.

For instance, I had to figure out what was GCC generating for C++
exceptions. There was NO documentation, and all you had is several
huge files without a single comment, not even a comment that describes
what the file is supposed to do. It took me several months of work
till I figured it out. For instance, one (uncommented) pitfall was that
the assembler did not assemble what you wrote in some cases.
It "optimized" your instructions, merging some data to save space.

It took me several days to figure that the assembler was the culprit...
and that it was OK that the generated code did NOT conform the DWARF
specs.

But I could figure it out eventually. Compare that to windows.

Under windows I didn't have the source code but I had an API
(documented!). You just call a function with a series of well
described tables and that was it. It took me only several days.

Conclusion:

It is better to have a documented API than a bunch of C source
code that you have to figure out!

jacob

 

[Nick Keighley]

OK, so you move all the code into derive_snafu_context() and then you
comment *that*. What's the benefit?




That's because this sort of template is ugly as sin.

it's not just the layout but the zero information content that makes
it ugly. If you can read C you can see what arguments it takes and
what type it returns

 

[jacob navia]

Nick Keighley a écrit :

it's not just the layout but the zero information content that makes
it ugly. If you can read C you can see what arguments it takes and
what type it returns

You are completely missing the point here. As in ALL COMMENTS, the thing to describe
there is not what type the arguments are, but what they MEAN.

You should NOT write:

argument "a" is an int

but

argument "a" is the number of hits since last checkin.

for instance.

 

[Nick Keighley]

<7f6fa240-c9d1-448f-a595-277940d3b...@b35g2000yqi.googlegroups.com>,

[...] I hate those code templates that demand a header
like this
/*
 * Name: derive_snafu_context
 *
 * Arguments: none
 *
 * Return: none
 */
void derive_snafu context ()
{
}
that sort of stuff drives me mad.

That's because this sort of template is ugly as sin.

Perhaps ugly, but perhaps informative.

more often than not, not informative

 Especially when the template has an
*abstract* explaining what a snafu context is and the approach taken to
derive it.

you'll be amazed how many programmers don't know what "abstract"
means. My style would be to describe what a snafu context was, either
here or wherever its corresponding data structure was.

Pull some random Linux source out that you aren't intimately familiar with -
and anything over a half dozen lines tends to be gibberish.  So you spend a
few hours analyzing uncommented logic with "clever" but meaningless routine
names and even less informative variable names.  When the programmer could
have spent a few minutes explaining it - heck, even explaining how clever
his naming is.

I do try to comment what is not obvious. The refactoring people would
expect sane identifier names.

I comment for myself, knowing that after time passes - even I need to
re-remember why I did what I did.

I was only railing against information free comments. And the
refactoring people have a point that good choice of names can save you
some comments.

 

[Nick Keighley]

Nick Keighley a crit :

you don't have a comment like the one I described... The whole point
is you end up with a bunch of tiny self evident functions.

You are completely missing the point here. As in ALL COMMENTS, the thing to
describe there is not what type the arguments are, but what they MEAN.

no I am not missing the point. I see comments exactly as I'm
describing.

"teach not your mother's mother to extract the embryonic juices of the
bird by suction"

You should NOT write:

argument "a" is an int

but

argument "a" is the number of hits since last checkin.

for instance.

or use a meaningful typename (bit hard in this case)

void gen_report (FILE *report, Hit_count hits)

 

[Nick Keighley]

FredK a crit :




The only comm ents I find in the gnu source code is the  FSF copyright
notice at the beginning of each file. This is a constant problem.

For instance, I had to figure out what was GCC generating for C++
exceptions. There was NO documentation, and all you had is  several
huge files without a single comment, not even a comment that describes
what the file is supposed to do. It took me several months of work
till I figured it out. For instance, one (uncommented) pitfall was that
the assembler did not assemble what you wrote in some cases.
It "optimized" your instructions, merging some data to save space.

It took me several days to figure that the assembler was the culprit...
and that it was OK that the generated code did NOT conform the DWARF
specs.

But I could figure it out eventually. Compare that to windows.

Under windows I didn't have the source code but I had an API
(documented!). You just call a function with a series of well
described tables and that was it. It took me only several days.

Conclusion:

It is better to have a documented API than a bunch of C source
code that you have to figure out!

strike one for closed source! Next time one of Stallman's acolytes
creeps up behind me a belts me with a rolled up copy of the Public
Virus I'll have another answer!

 

[bart.c]

it's not just the layout but the zero information content that makes
it ugly. If you can read C you can see what arguments it takes and
what type it returns

Types are often irrelevant. But sometimes a parameter or return value has
complex behaviour that can't expressed in an identifier, without making it
ridiculously long. And there might be interdependencies.

And sometimes there aren't any parameters, and there is no return value! The
name of the function can only express so much.

Most C sources I've looked at (for open source software), seem to be
completely devoid of comments, other than licensing text, list of authors,
and version numbers. As to what it actually does, nothing!

 

[Mark]

Perl scripts are used for "write once use twice" code. Everybody
knows that, and writing comments on such code is seen as a waste
of time.

But as always, perl scripts tend to be used far more than their
writers thought it would be possible.

It's possible to write reasonable Perl which is well-designed and
maintainable. While we use C a lot, sometimes Perl (or, shock horror,
Perl embedded in C or C embedded in Perl) or another language is
more appropriate.

We have good Perl which has done good service for us for over 10 years
now - and hasn't been significantly more trouble to maintain than our C,
Fortran or Python programs, and significantly less trouble than our C++.

Just because it's possible to write bad Perl (and it is), doesn't mean
it's impossible to write good Perl.

Of course: if all you have is a hammer, everything looks like a nail!

 

[Nick Keighley]

That's because this sort of [comment] template is ugly as sin.

it's not just the layout but the zero information content that makes
it ugly. If you can read C you can see what arguments it takes and
what type it returns

Types are often irrelevant.

I'm not so sure they are. Well chosen types can make a lot of
difference. I sometimes find I can omit the parameter names in the
header file because it is quite clear what the function does without
them. (I believe people should have enough infomation to be able to
use my functions without having to read the C file)

But sometimes a parameter or return value has
complex behaviour that can't expressed in an identifier, without making it
ridiculously long. And there might be interdependencies.

yes this can happen. I'm not a "write no comments!" kind of guy. It's
just that I want their SNR to be high rather than low.

And sometimes there aren't any parameters, and there is no return value!

what the Agile people would call a "code smell"...

The name of the function can only express so much.

which kind of implies your functions might be doing too much. Even the
Structured Programming crowd suggested that you should be able to
describe a function in a short sentence.

Most C sources I've looked at (for open source software), seem to be
completely devoid of comments, other than licensing text, list of authors,
and version numbers. As to what it actually does, nothing!

not a style I like

 

[Richard Bos]

JN> A programming language doesn't avoid bugs. Mistakes can be done
JN> in any programming language.

JN> malloc/free bugs?

JN> Use a GC in C.

JN> Zero terminated strings problems?

JN> Use a counted string library.

What is so magical about C that means that it's preferable to use a
custom string library, a custom hash/map/dictionary library, a custom
counted string library, a custom regular expression library, and
probably a half-dozen other custom libraries than to use a language
that's better suited to the problem?

The magic is not in C. The magic is in a _very specific implementation_
of C.

Richard

 

[Malcolm McLean]

which kind of implies your functions might be doing too much. Even the
Structured Programming crowd suggested that you should be able to
describe a function in a short sentence.

No, that they are poorly organised

char *translatetofrench(char *english)

is a perfectly well-formed function. Of course if it is any good it
will call many thousands of subroutines, and it will never give
perfect results on all input.

int is_vowel(char ch)

is probably one of the subroutines it will call, deep down in the
logic. Again, this is a perfectly-well formed fucntion.

 

[wolfgang.riedel]

news:[email protected]...

Let's see: not worrying about allocating or growing dynamic arrays,
forgetting memory management for them, being able to deal with entire arrays
at once,

use APL
(and buy a new keyboard)

not bothering about ... syntax,

OK, don't!

Wolfgang

 

[wolfgang.riedel]

It's not a portable program by any means, but I genuinely feel that there was
no reasonable alternative to writing it in C.  

seems, after reading the (you guess it) README,
a quite interesting project - but
why for a goddess sake, am I greeted/urged at

http://github.com/wrpseudo/pseudo

by a
'You have to install' some Flash Player
on any and every link?
I don't want to!
Wolfgang

btw.: I have used the 'wr' prefix in some of my lib's for obvious
reasons,
where's yours from?

 

[Seebs]

by a
'You have to install' some Flash Player
on any and every link?
I don't want to!

No clue. I don't have flash installed and I don't encounter that. Is
it possible that something on your system is acting up? Or it could be that
you're seeing ads I don't.

btw.: I have used the 'wr' prefix in some of my lib's for obvious
reasons,
where's yours from?

Wind River, the employer that funded the project.

-s

 

[wolfgang.riedel]

That said,
I have never been able to bring myself to like the language even though
I am fully aware of its power of expression; ...  There is just something about
the language that tends to turn many of us off in a way not no other
language that I have encountered has managed.

Yes, (I had to read and port perl programs to C++) -

And no, I know, it has wonderful features; it changes your thinking
about
programming etc. and I have read lots of books, mostly by supporters,
but
- I dislike Lisp et relatives as much!

(These two are just ugly! APL is simply incomprehensible)

I think, every developer has some aesthetic sense -
for programs and for programming languages.
While the preference for a PL might be historic and personal,
I think, a greater agreement exits of programs, that 'smell' -
somehow!

(As for scripting, I use Rexx since 20 years, over s.th. like 20
platforms,
where possible - where not an unhappy mix of .bat, 4NT, sed, bash,
awk and - perl)

Wolfgang