> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
