Obviously, the program has to meet the specs.

What I was trying to get across was that you make the code readable from
the outset; if you KNOW that you are going to have to do something
convoluted in order to make it meet the spec (like using a pointer to a
pointer to a pointer to a procedure which uses pointer to pointers), do
so. But if everything else is readable, and you are in the habit of
making things readable, then you can spend a bit of time to make the
convoluted code readable.

If the initial version is readable, and while testing you discover it is
too large or too slow (or if using the XC8 free compiler, BOTH :) then
you can tweak things.

There is no reason why readable code cannot be just as compact and just
as fast as spaghetti code.

Things that help to make code readable are good program structure  (if
performance won't suffer, break things up into small procedures), use
meaningful variable can constant names, be consistent in your naming
conventions, and use comments to describe WHY a piece of code is doing
something. WHAT it is doing should be evident from the code itself. And
if it isn't evident, then indeed comment that as well.

I hope I'm not preaching to the choir, but I spent far too many hours in
my career trying to figure out what on earth THAT piece of code is
doing. And many times it was MY code.
--=20
Larry Bradley =20
Orleans (Ottawa) Canada=20

On Sun, 2014-04-13 at 18:06 +0200, Wouter van Ooijen wrote:

> > Code should be maintainable but within limits - firstly the code=20
> should do what it is supposed to.
>  > If it meets this criterion why does it need to be maintained?
>=20
> Because requirements never stay thye same.
>=20
> But I agree that 'meeting its specs' is definitely first, and=20
> 'maintainable' a (close?) second.
>=20
> Wouter
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.