At 10:45 AM 12/18/2007, Robert Meek wrote: > This has always been a picky subject for me! Having had little or >no formal programming instruction, I had to learn for myself what works best >for myself and my needs. Looking at the code of others helped somewhat, but >in the end as they were not specifically doing the same as I, I ended up >having to change much of it anyway. > I've always taken exception to those who constantly preach about not >using global variables, goto's, and the like, just as a matter of principle >because if it solves a problem, works, and doesn't cause problems, who >should say that it is wrong to use simply because they don't like it, or >even if the method might actually be more prone to adding problems to one's >code. It's a matter of choice and whether or not you can ensure that it >works as wanted without causing problems!
I find that most recommended practices are not based on theory but on practical experience. Just as you say you work out what works for you, others do the same. They then pass on recommendations based on their experience. For example, the recommendation to not use GO TO is based on lots of experience of dealing with code full of those statements. A large group of developers who each had to deal with inheriting a code base full of GO TO statements have collectively concluded that the problems they can create are so bad that use of GO TO should be strongly discouraged. I would listen carefully to this advice. Of course, we now have several generations of developers who have heard this advice their entire lives and repeat it as a mantra because they, themselves, have not experienced the pain of dealing with a program full of GO TO statements. As they become team leaders and managers, should be chastise them for repeating what others learned by painful experience? I don't think so. Now, I also believe that every rule has exceptions. So, if you can argue a case for using a GO TO here and there, great! But I wouldn't discard what is "preached" just because I haven't yet run into the problems that the preaching addresses. Instead I would listen carefully to the lessons embedded within the recommendations. _______________________________________________ Delphi mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
