Recent work on Leo's new beautify-c command reminds me just how much I
despise the C language.
1. The Gnu indent program has a gazillion options, but apparently
*none* of them automatically insert curly brackets in code such as
this, taken from gperf-cc.c::
if (*str == *s && !memcmp (str + 1, s + 1, len - 1))
return &wordlist[index];
The Gnu code and documentation talk out of both sides of their mouth
regarding how much of C indent actually does know about.
In order for c-to-python to work properly, this must be changed to
something like::
if (*str == *s && !memcmp (str + 1, s + 1, len - 1))
{
return &wordlist[index];
}
After quite a bit of work, beautify-c now does this. Yes, this means
that beautify-c *does* understand a bit of C. The parsing is flimsy,
and done at the token level.
2. Here is a cute C gotcha, taken from http://en.wikipedia.org/wiki/Indent_style
A statement mistakenly inserted between the control statement and the
opening brace of the loop block turns the body of the loop into a
single trip::
for (int i = 0; i < total; i++)
whoops(bar); /* repeated total times */
{
only_once(); /* Programmer intended this to be done total
times */
} //for (i) <-- This comment is no longer valid, and is very
misleading!
The compiler probably should issue a warning about this, especially in
situations, as shown, where the compound statement does not start with
any declarations. Maybe there already is such an option, buried in
the gazillions of gcc options...
3. The gnu indent program comes with a fairly complete set of
regression tests. They test that the present version of indent
generates the same output as the previous version did. This is better
than nothing, but these tests are in no way unit tests because they
test the program as a whole rather than testing the individual units
of the code.
The tests are written as shell scripts, presumably because there
really isn't any framework in the Gnu project for unit testing C
code. To be fair, the Gnu project began life decades before unit
testing was invented. Still, the testing frameworks for Gnu indent
sucks by modern standards. One has more than the suspicion that C's
crappy qualities ensure that this will never change.
All this highlights the major challenge in using larger units as the
unit of programming. The larger the units, the less flexible they
tend to be and the more difficult it is in practice either to
understand them or to use them constructively.
However, these "challenges" do not mean that the project is a bad
idea. Indeed, this new point of view has already given Leo the
beautify-c and c-to-python commands. So maybe the "larger units" act
as more of an inspiration or catalyst rather than an actual source of
working code...
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
