Prev: System Calls
Next: Warning to newbies
From: ImpalerCore on 16 Mar 2010 15:42 On Mar 16, 2:40 pm, Andrew Poelstra <apoels...(a)localhost.localdomain> wrote: > On 2010-03-16, ImpalerCore <jadil...(a)gmail.com> wrote: > > > > > On Mar 16, 12:51 pm, Jonathan de Boyne Pollard <J.deBoynePollard- > > newsgro...(a)NTLWorld.COM> wrote: > >> >> If an obscure technique is being employed, then a comment to that > >> >> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments > >> >> along the following lines ... > > >> >> x := X + 1 ; increment x > > >> >> ... which only serve to increase the noise floor. > > >> > In our shop, those appeared when we got the idiotic edict that each > >> > line had to have a comment. > > >> Such edicts make one want to write code in the form > > >> x /* The variable x */ > >> = /* is assigned */ > >> x /* its value * / > >> + /* plus * / > >> 2 /* one */ > >> ; /* . */ > > > It also shows that maintaining these kinds of comment are more trouble > > than the comment is worth. The maintenance of these comments is way > > higher than the information they give, i.e. Who forgot to change the '/ > > * one */' to '/* two */'? > > x /* The pointer */ > -> /* equals */ > x /* itself */ > = /* minus */ > 2 /* five */ > ; /* :( */ Then you start questioning which is right, the comment or the code, which can end up leading to a lot more work to figure it out. > -- > Andrew Poelstrahttp://www.wpsoftware.net/andrew
From: Nick Keighley on 17 Mar 2010 05:52 On 16 Mar, 18:13, 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: > >>> If an obscure technique is being employed, then a comment to that > >>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments > >>> along the following lines ... > > >>> x := X + 1 ; increment x > > A true CLC pedantic would point out that the above does not increment x > (unless x and X have the same value). it plainly isn't C. Perhaps in whatever-it-is-written-in cares about case. What *is* it written in? > >>> ... which only serve to increase the noise floor. > > >> In our shop, those appeared when we got the idiotic edict that each > >> line had to have a comment. > > >Such edicts make one want to write code in the form > > > x /* The variable x */ > > = /* is assigned */ > > x /* its value * / > > + /* plus * / > > 2 /* two */ > > ; /* . */ > > Correction applied. HTH. #include "crlzyzz.h" /* obvious meaning */ if it's obvious, why did you comment it?
From: jmfbahciv on 17 Mar 2010 08:03 Jonathan de Boyne Pollard wrote: >> >>> >>> If an obscure technique is being employed, then a comment to that >>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments >>> along the following lines ... >>> >>> x := X + 1 ; increment x >>> >>> ... which only serve to increase the noise floor. >>> >> In our shop, those appeared when we got the idiotic edict that each >> line had to have a comment. >> > Such edicts make one want to write code in the form > > x /* The variable x */ > = /* is assigned */ > x /* its value * / > + /* plus * / > 2 /* one */ > ; /* . */ > And would make all tapes spill over to two magtapes. Fortunately, your code would produce many detected errors. /BAH
From: jmfbahciv on 17 Mar 2010 08:05 ImpalerCore wrote: > On Mar 16, 2:40 pm, Andrew Poelstra <apoels...(a)localhost.localdomain> > wrote: >> On 2010-03-16, ImpalerCore <jadil...(a)gmail.com> wrote: >> >> >> >>> On Mar 16, 12:51 pm, Jonathan de Boyne Pollard <J.deBoynePollard- >>> newsgro...(a)NTLWorld.COM> wrote: >>>>>> If an obscure technique is being employed, then a comment to that >>>>>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments >>>>>> along the following lines ... >>>>>> x := X + 1 ; increment x >>>>>> ... which only serve to increase the noise floor. >>>>> In our shop, those appeared when we got the idiotic edict that each >>>>> line had to have a comment. >>>> Such edicts make one want to write code in the form >>>> x /* The variable x */ >>>> = /* is assigned */ >>>> x /* its value * / >>>> + /* plus * / >>>> 2 /* one */ >>>> ; /* . */ >>> It also shows that maintaining these kinds of comment are more trouble >>> than the comment is worth. The maintenance of these comments is way >>> higher than the information they give, i.e. Who forgot to change the '/ >>> * one */' to '/* two */'? >> x /* The pointer */ >> -> /* equals */ >> x /* itself */ >> = /* minus */ >> 2 /* five */ >> ; /* :( */ > > Then you start questioning which is right, the comment or the code, > which can end up leading to a lot more work to figure it out. > This code is unreadable. One of the reasons I don't like HLLs for basic OS coding. It's very nice to be able to scan the listing just like the CPU would do when executing. /BAH
From: jmfbahciv on 17 Mar 2010 08:07
Nick Keighley wrote: > On 16 Mar, 18:13, 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: > >>>>> If an obscure technique is being employed, then a comment to that >>>>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments >>>>> along the following lines ... >>>>> x := X + 1 ; increment x >> A true CLC pedantic would point out that the above does not increment x >> (unless x and X have the same value). > > it plainly isn't C. Perhaps in whatever-it-is-written-in cares about > case. > > What *is* it written in? > > >>>>> ... which only serve to increase the noise floor. >>>> In our shop, those appeared when we got the idiotic edict that each >>>> line had to have a comment. >>> Such edicts make one want to write code in the form >>> x /* The variable x */ >>> = /* is assigned */ >>> x /* its value * / >>> + /* plus * / >>> 2 /* two */ >>> ; /* . */ >> Correction applied. HTH. > > #include "crlzyzz.h" /* obvious meaning */ > > if it's obvious, why did you comment it? > > > Now that one may have usefulness :-). If it's not obvious to the reader, then a search for the author or his/her specs is in order. /BAH |