Hi Matti,
Matti Karnaattu wrote on Wed, Sep 24, 2014 at 08:14:27PM +0300:
> I think that it is not defined enough unambiguously, how ideal code
> looks like. It reduces motivation to improve code better, if it is not
> defined, what is better.
>
> style(9) is good, but it would be better if there is reference component
> that is optimized to perfection, including tests, naming conventions,
> file hierarchy etc.
>
> Then ALL code changes and new code can be compared to that reference,
> and that reference code can be used to build templates & automated
> testing.
It's not as easy as that. Not only is the code constantly improved,
our standards which idioms are considered good and which are considered
dangerous constantly evolve as well, slowly turning new, high quality
code into old code of lower quality - even if the code remains
completely unchanged. Actually, the quality of code diminishes in
time *in particular* when it remains unchanged.
As a recent example, imagine that you have an array allocated with
calloc(3) and want to change its size. Until quite recently, the
following was considered reasonable code:
elemsz = ...;
nelem = ...;
if (SIZE_MAX / nelem < elemsz)
handle_overflow();
newp = realloc(pointer, nelem * elemsz);
if (newp == NULL)
handle_oom();
pointer = newp;
Now, that is considered a dangerous idiom, to be rewritten as
follows:
elemsz = ...;
nelem = ...;
newp = reallocarray(pointer, nelem, elemsz);
if (newp == NULL)
handle_oom();
pointer = newp;
Besides, as i already said at an earlier occasion, it is highly
non-trivial to write down a comprehensive set of rules to be
followed, it will end up being incomplete, too dogmatic, and
outdated all at the same time.
The best way to learn is to read code, understand it, find
weaknesses, suggest improvements, and when we agree on the
improvements, systematically audit the tree for similar
problems.
Actually, that's not just the way for newbies, it's how the most
experienced developers do it, too. And even they, now and then,
have to delete suggestions for improvments from their trees that,
when reviewed, turn out to have downsides.
Yours,
Ingo
