From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,deac256a05c84a59 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Marc A. Criley" Newsgroups: comp.lang.ada Subject: Re: DOM and SAX parsing in Ada Date: Thu, 27 Jan 2005 14:57:42 -0600 Message-ID: <35t2u6F4qc335U1@individual.net> References: <41900010.D28DD400@boeing.com> <9CWjd.17305$5K2.1356@attbi_s03> <1106223415.857525.176640@c13g2000cwb.googlegroups.com> <41F4DB6F.4090909@mailinator.com> <35nh12F4oe4caU1@individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net HDiAxwxj63TJXBAJNCahbAPaJDl8q/5bVvCEpkUEZf2DNzsdMh User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:8025 Date: 2005-01-27T14:57:42-06:00 List-Id: Nick Roberts wrote: > > I told the AdaCore employee that I wanted to make a large number of small > changes (a lot of comments that would help identify fragments of code, for > referential maintenance documentation), and he responded that he felt such > changes were not necessary. I took this to imply (although admittedly he > didn't say so explicitly) that he wouldn't accept these changes into the > AdaCore CVS repository. On this basis, I was assuming that I would have to > create a forked project on some other repository (of course it doesn't have > to be SourceForge per se). Ah, I see now. Frankly, I can see both parties' points. On the one hand, it's certainly a good thing to improve (or create) the documentation or commenting of a product. And one certainly wants to commend and encourage any programmer motivated to do that :-) On the other hand, any change to a piece of software could accidentally modify it in an unintended way. Obviously not the addition of the comments themselves, but for instance if a block of comment text were being cut and pasted, a slip of the mouse could accidentally pick up an adjacent line of code and move it. Bad things could then happen, which might now show up right away if this happened on a code path that is infreqently executed. IMHO, modifying files just to fix and add comments has risk. Small, certainly, but it's not zero. And if you're talking about modifying lots of files to do this, that risk is there for each file. I would certainly love to see commenting improve, but I have to weigh that against the small risk of something that works just fine getting accidentally broken, i.e., "if it ain't broke, don't fix it". And for me, barring some externally imposed coding/commenting standard, I come down just barely on the side of leaving it alone. I suspect the AdaCore employee in question (to whom I've submitted bug reports that have been accepted and the fixes for which I know have been incorporated) feels much the same way, but for him you also have to add in the time that it would take to verify your updates for accuracy and to ensure there was none of the accidental modifiation that I mentioned above, which takes time away from his other AdaCore business tasks. So he has to weigh (time to verify update and not work on functional bugs and improvements + risk of unintended modification) versus (value of documentation update with no improved functionality). He's not being unreasonable, just weighing dollars versus benefit. Marc