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=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,f292779560fb8442 X-Google-Attributes: gid109fba,public X-Google-Thread: 10db24,30e368bdb3310fe5 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,af40e09e753872c X-Google-Attributes: gidfac41,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public From: jdege@winternet.com (Jeff Dege) Subject: Re: Hungarian notation Date: 1996/06/02 Message-ID: <4oqphq$6or@blackice.winternet.com>#1/1 X-Deja-AN: 157985188 references: <31999F43.41C67EA6@scn.de> <4o07o9$rfu@seagoon.newcastle.edu.au> <4o1vo3$p2a@news1.ni.net> <4oehnp$onn@goanna.cs.rmit.EDU.AU> <31B0EE2A.59E2@cell.cinvestav.mx> followup-to: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel organization: StarNet Communications, Inc newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel Date: 1996-06-02T00:00:00+00:00 List-Id: On Sat, 01 Jun 1996 18:28:10 -0700, Heinz Hemken (hhemken@cell.cinvestav.mx) wrote: : : Sparse comments due to "it's in the code", or because "the language : itself expresses what you need to say" will backfire with certainty one : day. It isn't poetry or literature, though it may often seem so, nor is : it an academic exercise, though many seem to think so. It is something : that MUST function and evolve correctly. In that light, it's probably : better to err in the direction of more comments rather than less. One of the fundamental principles of building non-fragile software (i.e., software that doesn't break in maintenance) is to _never_ allow redundant information. If a system depends upon two or more pieces of information being in synch in order to work, it is broken, or it will be after a couple of maintenance cycles. Duplicating in the comments information that is clear from the code opens the possibility that the comments will differ from the code, which will result in programmers coding as if the comments are correct. So I err in the direction of commenting what isn't in the code. I.e., what something is supposed to do, why I did I do this, why didn't I do that, what unexpected interactions might arise. And, of course, a continous log of changes and reasons for them. -- You'd think that after all this time I would have dreamed up a really clever .sig!