[clug] July Programming SIG: the fourteen principles for new programmers

[David]

Paul Wayper wrote:
>
> The CLUG PSIG's principles for new programmers to learn:

It's interesting, I've started with basically these views but have
gradually moved further and further away from them.

> 2) If you do have to write from scratch, try to think of the large cases.
> The more you build in limitations, the more you will inevitably have to
> remove them later.  Your choices in the future will be harder than they
> are now.

If you try and think of all the limitations you end up with a floating
car.  It drives everywhere but it's a crap boat and a crap car.

There are far too many possible things that might happen in the future.
 Even if you design in a dozen of them, the odds are that whatever does
happen will be different enough that the code will have to be changed,
and you've just complicated things by adding eleven other bits of
functionality which aren't used or needed.  As you maintain it the
unused functionality breaks slightly and thinks just slide further down
hill.

So I increasingly design code to do exactly what I want it to do and
simply accept that if I want to change it's usage I need to change the
code.  There's no point adding a pile of code to allow you to change
communication protocols if you have no plan to ever change it.


> 3) Write things to be modular.  Make them behave well.  Be liberal in
> what you accept, and strict in what you output.  Use standards where
> possible - after all, there are so many to choose from.

I really don't like being liberal in what you accept.  It makes your
code complex and hideous.  It also leads to unpredictable behaviour, if
your program takes a date string you have terrible issues.  What's
08/05/03?  year/month/day, day/month/year, month/day/year?  And if you
have two modules written by different people who are liberal in what
they accept, are they going to parse it in the same way?

I think the idea of only taking well documented strict values is the
better way to go long term.  If it isn't what you expect then throw an
error, guessing just causes problems for everyone.

> 10) Program the first one to be thrown away, because you will anyway.
> This works with 2 because you will learn more about what your program
> needs to do by writing it than in theorising, and you want to produce
> code not theorise.  You may find it easier to not tell your
> management about the first one in case they want to keep it.

I think this concept doesn't work once you start to scale.  If it's
something that takes two days and has one person working on it then this
might be a good idea.  For a product that takes several years to develop
it's completely insane.

Prototyping is one thing, creating a prototype isn't the same as
creating the end program.

Refactoring code after isn't been worked on for a while is also a good
idea, but it's not throwing away the earlier work and shouldn't be
presented as such.


David