lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coding practices


From: David Kastrup
Subject: Re: Coding practices
Date: Sat, 16 Feb 2013 17:53:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, Feb 16, 2013 at 3:46 PM, David Kastrup <address@hidden> wrote:
>
>> I was talking about "reasonable documenting and coding practice".
>> That does not involve how to structure things.  As I said, we are
>> talking about post-1960s Pascal coding, and he tried his best to
>> still present things in a structured way, in well-documented
>> meaningful chunks.
>>
>> Nowadays we have much more modular programming languages, and we make
>> a mess of it.  I consider doing good work with bad tools a better
>> example than doing bad work with good tools.
>
> What is your practical advice for coding practices, then?

Recently, a man was fired in the U.S. after system administrators found
an open VNC connection from China into their network.  The initial
suspicion of a hacker attack was wrong.  It turned out that the
programmer was surfing the Internet and Paypal all day.  His work was
done via VNC connection by a Chinese programmer getting about a third of
his pay.  The rig apparently had been going on for a considerable amount
of time (like years), with the code from the programmer getting
consistent high marks from colleagues.  I am not surprised.

I would suggest to code like that Chinese programmer, so that any
questions regarding the code will get a plausible "Let's see, what was I
thinking here?  Wait, I remember this was a bit more complex, be back in
a minute." reply, with your "partner" actually being able to be back in
a minute.  Code in a manner that makes it possible for others to pretend
they have written it.  That means a clear layout and concise
documentation.  If you write code that others can get into fast enough
to pass them off as their own plausibly, you are doing a good job.

That means using patterns as expected, language paradigms as expected,
and documenting what might be unexpected.  It means being obvious and
not clever.  It means picking suitable tools for the job, taking more
time for finding the best way to do things than just doing whatever
comes into your mind first, and not coding at the limit of your
capacity.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]