Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill From: bill@twwells.uucp (T. William Wells) Newsgroups: comp.misc Subject: Re: Program Errors and developement environment Message-ID: <806@twwells.uucp> Date: 30 Mar 89 15:18:13 GMT References: <4352@enea.se> <2950@hound.UUCP> <3998@ttidca.TTI.COM> <1001@taurus.BITNET> Reply-To: bill@twwells.UUCP (T. William Wells) Organization: None, Ft. Lauderdale Lines: 34 Summary: Expires: Sender: Followup-To: Distribution: Keywords: In article <1001@taurus.BITNET> writes: : : Maybe the answer is the languages having "till the end of the line" comments, : such as Ada, PostScript, most Assembly languages, FORTRAN, etc. Maybe the answer is to just use due care and common sense. It works for me and my commenting style is /* text ... text text */ : This way, the programmer cannot delete code by mistake. I doubt there is language feature in any language that won't cause difficulty in interpreting results when misused. The solution? It certainly isn't to avoid all language features. Rather, learn coding styles that minimize difficult to diagnose problems. With my C comment style, I have to do these things: 1) check for embedded comments (via my normal linting); 2) if code must be commented out, use the preprocessor, and not comments; and, if code is commented out via the preprocessor, use a tag on the #ifdef (like notdef) that can be searched for so that such can be eliminated. The result? I don't lose code to comments. And I don't have the maintenance headaches that mandatory one line comments cause. --- Bill { uunet | novavax } !twwells!bill (BTW, I'm may be looking for a new job sometime in the next few months. If you know of a good one where I can be based in South Florida do send me e-mail.)