Re: Coding practices

[Werner LEMBERG]

> 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.

+1.  In particular, I force myself to document changes.  For example,
in both FreeType and groff, I still use a manually written ChangeLog
file (which then serves as the commit message to the CVS).  While it
costs an *enormous* amount of time to write it, I think this is well
invested time and justified.  With git, due to the ability to see the
code quickly, many people believe that a sloppy one-liner does the
job.

Quite a good source of good coding is the Linux kernel IMHO.  Even
tiniest changes have a very large amount of reasoning and
documentation.


    Werner