Although I cannot say for sure, never having been in the situation, I would think that if in a team situation the lead programmer would be expected to lay down certain "best practices" and "never do" rules so as to provide consistency and prevent certain types of errors they might otherwise be prone to. But when I first started coding I used to get upset with those who told me that using Global variables was not healthy but never explained why! Now I rarely use them at all, but only because I understand OOP much better and it's not necessary, not because it's allowed or not. In fact, using NET, I can opt to set my compiler to use them or not as wanted, so I still find it difficult to accept that doing so is sloppy programming! Pointers themselves will soon get the same reputation because they're not recommended for use under NET. They are considered "Unsafe", yet I know Delphi programmers who never write code without pointers! And it's not because they cannot or using them makes for better code, it's just their background, experience, and style!
from Robert Meek dba "Tangentals Design" e-mail: [EMAIL PROTECTED] Freelance Windows Programming for XP and Vista Also proud to be a Moderator of the "Delphi-List" at elists.org "Reality cannot be explained...only enjoyed or endured as your current perspective allows!" -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Chamberlin Sent: Tuesday, December 18, 2007 7:09 PM To: Borland's Delphi Discussion List Subject: RE: Avoiding form loops? 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 _______________________________________________ Delphi mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
