C in Science and Engineering...

On 8 June, 20:33, "FredK" <fred.nos...@dec.com> wrote:
> "Tim Streater" <timstrea...@waitrose.com> wrote in message
> news:timstreater-3F370C.16493908062010@news.individual.net...
> > In article
> > <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.

On 9 June, 09:22, jacob navia <ja...@nospam.org> wrote:
> Nick Keighley a crit :
> > On 8 June, 16:49, Tim Streater <timstrea...@waitrose.com> wrote:
> >> In article
> >> <7f6fa240-c9d1-448f-a595-277940d3b...@b35g2000yqi.googlegroups.com>,
> >> *Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >>> On 8 June, 15:24, "FredK" <fred.nos...@dec.com> wrote:

> >>>> 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.
>
> >> OK, so you move all the code into derive_snafu_context() and then you
> >> comment *that*. What's the benefit?

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.


> >>> 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.
>
> > 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.

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)

On 9 June, 01:09, jacob navia <ja...@spamsink.net> wrote:
> 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!

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!

Nick Keighley wrote:
> On 8 June, 16:49, Tim Streater <timstrea...@waitrose.com> wrote:
>> In article

>> 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

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!

--
Bartc

jacob navia <jacob@nospam.org> wrote:
>
> 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!

On 9 June, 10:16, "bart.c" <ba...@freeuk.com> wrote:
> Nick Keighley wrote:
> > On 8 June, 16:49, Tim Streater <timstrea...@waitrose.com> wrote:

> >> 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


--
And so when you think of the future,
imagine a Pentium stamping on a man's face,
forever.

Charlton Wilbur <cwilbur@chromatico.net> wrote:

> >>>>> "JN" == jacob navia <jacob@spamsink.net> writes:
>
> 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

On Jun 9, 2:08*pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
>
> 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.

On 5 June, 14:55, "bart.c" <ba...@freeuk.com> wrote:
> "Rui Maciel" <rui.mac...@gmail.com> wrote in message
>
> news:4c0a3c77$0$3337$a729d347@news.telepac.pt...

> 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

On 5 June, 22:15, Seebs <usenet-nos...@seebs.net> wrote:

> It's not a portable program by any means, but I genuinely feel that therewas
> 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?

On 2010-06-09, wolfgang.riedel <wolfgang.riedel52@web.de> wrote:
>> http://github.com/wrpseudo/pseudo
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 7 June, 14:30, Tim Harig <user...@ilthio.net> wrote:

> 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

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message
news:3b83b1c9-5a12-4dcf-8302-490c8566e351@y11g2000yqm.googlegroups.com...
On Jun 9, 2:08 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
>
> 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.

---

Which any "self respecting" Open Source author would name "crunchFrog()" and
"eh()" or something equally "cute".

On Jun 8, 10:33*pm, "FredK" <fred.nos...@dec.com> wrote:
> "Tim Streater" <timstrea...@waitrose.com> wrote in message
>
> news:timstreater-3F370C.16493908062010@news.individual.net...
>
>
>
> > In article
> > <7f6fa240-c9d1-448f-a595-277940d3b...@b35g2000yqi.googlegroups.com>,
> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
> >> On 8 June, 15:24, "FredK" <fred.nos...@dec.com> wrote:
>
> >> > 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.
>
> > 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.
>
> 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.

http://lxr.linux.no/#linux+v2.6.34/fs/namei.c#L1897

That's a pretty nice snippet, methinks. Granted, not all Linux kernel
code is written that way, but if you're a kernel newbie asking for
trouble there are other places you can start before looking directly
at the source code (documentation, dozens of tutorials, mailing lists
and so forth). Ironically, that's the same with every other non-
trivial project, regardless of the language used for the
implementation.

FredK a écrit :
> 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.
>

Does an accentuated letter count as vowel?
What table does this function use? Unicode? utf8? utf16?

You HAVE to explain stuff, even if the name is self evident!