Idiotic programming style edicts
in [General Programming]
|
Prev: System Calls
Next: Warning to newbies
From: jmfbahciv on 19 Mar 2010 08:47 Walter Bushell wrote: > In article <601.764T2654T5385823(a)kltpzyxm.invalid>, > "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote: > >> In article <hnt5bs22t2v(a)news4.newsguy.com>, jmfbahciv(a)aol (jmfbahciv) >> writes: >> >>> <grin> My language is MACRO-10. JMF was always tickled whenever >>> he assembled some code because MACRO would report a "successful" >>> assembly with the comment "No errors detected". Think about it. ;-) >> "As far as we know, the system has never had an undetected error." > > > That is true of *all* the code I have wrote. > Not mine. I always write an off by one bug. /BAH
From: jmfbahciv on 19 Mar 2010 08:49 Patrick Scheible wrote: > Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups(a)NTLWorld.COM> writes: > >>> >>> Agreed. But note that the "its value" and "plus" comments aren't >>> properly terminated, so the "/*" on the "its value" line introduces a >>> comment that isn't terminated until the "*/" on the "one" line. The >>> net result is "x = x;" >>> >> Hooray! At last! Well spotted. I've been waiting to see how long it >> took and how many would do so. >> >> So not only does the mandatory comment on every line not match the >> apparent code, but the apparent code isn't the actual code, as a direct >> consequence of the mandatory comments. >> >> I'm assuming that M. Shanahan either spotted this too, or would have >> done so. > > Lessons: > > Even a small change, like adding a comment, can introduce a bug (as > Barb has been saying). > > A syntax-highlighting editor can be helpful in reducing trivial errors. > <snip> You are optimistic. In my shop, the high-lighting would also be buggy since we'ld have been developing and maintaining that software, too. I'm glad we had stupid terminals during our hayday. /BAH
From: jmfbahciv on 19 Mar 2010 08:51 spinoza1111 wrote: > On Mar 18, 9:19 pm, jmfbahciv <jmfbahciv(a)aol> wrote: >> spinoza1111 wrote: >>> On Mar 17, 2:13 am, gaze...(a)shell.xmission.com (Kenny McCormack) >>> wrote: >>>> In article <IU.D20100316.T165150.P1185...(a)J.de.Boyne.Pollard.localhost>, >>>> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...(a)NTLWorld.COM> wrote: >> <snip> >> >>>>> Such edicts make one want to write code in the form >>>>> x /* The variable x */ >>>>> = /* is assigned */ >>>>> x /* its value * / >>>>> + /* plus * / >>>>> 2 /* two */ >>>>> ; /* . */ >>> Nothing wrong with this style of commenting in assembler, at all. And, >>> this code sample looks like the one byte per instruction language >>> Mouse. >> <snip> >> >> Are you nuts? > > No, just that rarity: a competent programmer (the best one in this > newsgroup, probably) Now I know you have a 99% reality filter. >who's literate. Wrong. there are more capable people in a.f.c. >You snipped this: <snip> /BAH
From: jmfbahciv on 19 Mar 2010 08:53 BruceS wrote: > On Mar 18, 11:10 am, Patrick Scheible <k...(a)zipcon.net> wrote: >> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...(a)NTLWorld.COM> writes: >> >> >> >> >> >>>> Agreed. But note that the "its value" and "plus" comments aren't >>>> properly terminated, so the "/*" on the "its value" line introduces a >>>> comment that isn't terminated until the "*/" on the "one" line. The >>>> net result is "x = x;" >>> Hooray! At last! Well spotted. I've been waiting to see how long it >>> took and how many would do so. >>> So not only does the mandatory comment on every line not match the >>> apparent code, but the apparent code isn't the actual code, as a direct >>> consequence of the mandatory comments. >>> I'm assuming that M. Shanahan either spotted this too, or would have >>> done so. >> Lessons: >> >> Even a small change, like adding a comment, can introduce a bug (as >> Barb has been saying). >> >> A syntax-highlighting editor can be helpful in reducing trivial errors. >> >> Languages in which the end of the line ends a comment (such as C++, >> Ada, Unix shell scripts, Icon, others) reduce or contain syntax >> errors. > > <OT> AIUI, C++ accepts /* */ multiline comments without artificially > terminating said comments at the end of line. I don't have a C++ > Standard in front of me, so I can't confirm that it isn't simply an > artifact of environments in which I've written C++, but I'm relatively > confident that these work the same as in C. </OT> > > According to The C Standard, 6.4.9p2, C allows comments that *do* > automatically terminate at the end of the line, just as this style of > comment works in C++. One could avoid the bug in the earlier code by > writing it: > > x // The variable x > = // is assigned > x // its value > + // plus > 2 // pi > ; // . > > Oh, I'd better put in a :) or we'll have started another pointless > whinefest. We had a TECO macro which was run over the monitor sources after the weekly edit to match angle brackets. Do you have to do the same thing for C's multiple line comment characters (or any other language)? /BAH
From: jmfbahciv on 19 Mar 2010 08:57
Mensanator wrote: > On Mar 18, 6:09 pm, Larry__Weiss <l...(a)airmail.net> wrote: >> Mensanator wrote: >>> On Mar 18, 2:43 pm, Keith Thompson <ks...(a)mib.org> wrote: >>>> BruceS <bruce...(a)hotmail.com> writes: >>>> [...] >>>>> <OT> AIUI, C++ accepts /* */ multiline comments without artificially >>>>> terminating said comments at the end of line. I don't have a C++ >>>>> Standard in front of me, so I can't confirm that it isn't simply an >>>>> artifact of environments in which I've written C++, but I'm relatively >>>>> confident that these work the same as in C. </OT> >>>> In both C and C++, a comment that begins with /* is not >>>> "artificially" terminated at the end of the line. Instead, it's >>>> "artificially" terminated by the next */. (In other words, I'm >>>> not sure what's so artificial about it.) >>>>> According to The C Standard, 6.4.9p2, C allows comments that *do* >>>>> automatically terminate at the end of the line, just as this style of >>>>> comment works in C++. >>>> [...] >>>> Yes, both C and C++ now permit comments introduced by // and >>>> terminated by the end of the line. These were introduced in BCPL, >>>> one of C's distant ancestors from the 1960s. But they were dropped >>>> from C, and only reintroduced by the 1999 ISO C standard (which >>>> superseded the 1990 ISO C standard, which itself superseded the >>>> de facto standard of Kernighan & Ritchie's book). C++ has always >>>> supported // comments. >>>> Today, most C compilers fully support at least the C90 standard, >>>> but only a subset of the C99 standard. // comments are very widely >>>> supported. On the other hand, they can be rejected if you choose >>>> to invoke your C compiler in a strict C90-conforming mode, or if >>>> you're using a sufficiently old compiler, so /*...*/ comments are >>>> arguably more portable. // comments can also cause problems in >>>> Usenet posts; implicit line wrapping can introduce syntax errors. >>>> (Most people here in comp.lang.c already know this stuff; I'm posting >>>> it mostly for the benefit of those in alt.folklore.computers >>> Hey! Some of us folklorists actually DO know how to program. >> At least we think we remember that we know how to program. >> And some of us still demonstrate it by actually programming from time to time. >> >> Some of us wonder why we need all of these languages... >> http://en.wikipedia.org/wiki/List_of_programming_languages > > Oo, they even got Seed7 listed. > > Would you believe Seed7 actually has a function named "bigCLit"? > (Perhaps the author isn't up on American slang. I know he's European > because he spoke of not living on the same continent.) > Big C Literal? /BAH |