Hello Peter, I find that most programmes I've inherited as work are badly commented (one particularly memorable one had a function with all sorts of loops and internal functions: 1000+ lines of uncommented code, loop variables declared globally outside the function: a true gem); I try to give meaningful names to methods and to keep methods as short as possible: the end result is fairly self-commenting, helped by the OOP structure and reads a little bit like pseudocode; I comment the methods where necessary;
>I've found a few dirty tricks > (such as typecasting a class to expose private properties) I presume you can get inside an object with any pointer though; I am not a great fan of typcasting: I use it for derefencing objectlists, since it is the standard way of reading an object from a list, though I usually do it on the inside of a method which returns the object type instance (that is, the typecast occurs only within the list class itself): when using the list class, I do not need the typecast on the index of the list, but use the function method instead (its also clearer); > I like the saying: As soon as you idiot proof something, someone builds > a better idiot... I have been known to prepare objects with tested methods for group work, explained their use to juniors, and come back to find they have abandoned the class structure and written their own (buggy) code: I think some junior programmers think that OOP is a theoretical idea that you study in college, but which will not be useful in the real world (some frankly to not understand the basic concepts!) or that it stifles their "creativity" by compelling them to collaborate with others using a unified method; > which can led > to outright dangerous code. the most dangerous use of code I've seen recently was with badly assigned pointers in DLL's and with multiple initialisation of instances and assigning objects' owners as nil and not tidying up the memory: the DLL's concerned not only screwed up their own memory but also that of the calling menu program, but also made the other 20 DLL's used afterwards unstable; when you realise that all 20 DLL's had varying degrees of the same problem, you will imagine the difficulty I had in getting the structure functional; regards, Kevin ----- Original Message ----- From: "Peter" <[EMAIL PROTECTED]> To: "Borland's Delphi Discussion List" <[email protected]> Sent: Wednesday, April 26, 2006 4:13 AM Subject: Re: Delphi and Java > Hi Kevin, > Assembler programming showed me the need for clarity to the point where > even in Delphi, I comment most lines unless very very obvious. I've also > found that the programming language bears little relationship to the > readability or the debug-ability. I've had to help C programmers debug > nested IF statements even though I've never programmed in C. Invariably, > they tried to be clever in using the syntax. OOP does force you to > design your code more structurally, but I've found a few dirty tricks > (such as typecasting a class to expose private properties) which can led > to outright dangerous code. > > I like the saying: As soon as you idiot proof something, someone builds > a better idiot... > > Regards > Peter > _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
