On Wed, 27 Feb 2002 16:20:52 -0500, David Megginson <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>:
> Andy Ross writes: > > > Clearly this is an issue of personal style, but let me rattle off a > > few reasons why I think patch files are a better choice: > > [snip] > > I agree. Curt likes entire files so that he can use the Emacs > ediff-files command (if I recall correctly), but there's also an > ediff-revision command works the same way -- after applying the patch, > you can step through each change from the current CVS version, and > reverse changes you don't like. ..as the newbie here, I feel code comments should 0. explain _why_ "this new code is needed or desired", 1. explain _what_ "has, or not, been done before", 2. explain the _known_ alternatives, 3. explain _why_ "I do it myyyyy waaaaay", 4. explain _what_ "this code tries to do", and 5. explain _how_ "I do it myyyyy waaaaay". ..an higher comment-to-code ratio will help 0. evalauation of code 1. qc, qa and cvs'ing it into (and out of!) the code base, 2. help newbies onboard the developers team 3. helps prevent potential lawsuits or allegations of code theft (remember the Microsoft-source-code-on-email-to-Russia story a year or so back?) 4. will help develop airworthy code for EAA'ers like myself, that will pass FAA etc sertification tests with authority. ..and, I understand comments can be stripped out of the code on speed performance tweaking. ..btw, I learned to read patches here. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
