At 11:04 AM 5/1/2007, you wrote: > >> This whole discussion misses the point. Maintenance of the code > >> "trumps" all the merits of putting DIM statements in any > >> other place but the top of the method since putting DIM statements > >> within the code are negligible at best. If you scatter your DIM
> > That is absolutely and patently incorrect for proper maintenance of > > code -- putting the declarations of variables as close as possible to > > their use is one of the basic tenets of good software design. >This starts to border on religion. >How the heck did people write good software in C, Pascal or RB when >this capability was not available ? >Careful coding. > > Here's the kicker: If you have your declarations of variables in the > > immediate vicinity of their use, you have now made it possible to > > easily refactor that code simply by moving that entire block to a new > > location. Good discussion. I've gone back and forth about this, read lots of things about it. I was forced to put things at top BECAUSE OF REALBASIC earlier in their history. I actually started to like it. I think both arguments have merit. From the experts I read that "close as possible" is the agreed basic tenet. Because of that I have been knocked in a code review because I didn't do it. (Grr) Personally, I still put DIM at the top. Here's my reasons: -Unclutters code -Allows me to clearly invoke my initialization values -When I am writing a function, it's nice to have one place to go to where variables are declared -In C++, it avoids an error/warning if I'm using Labels and GoTo's (that's another subject!) and I "bypass" a variable -Eliminates bugs due to "shadow variables" -Forces functions to be shorter (another good programming tenet). If your declarations NEED to be closer to their usage, perhaps your function is too long in the first place! I disagree with the fellow who asserted that "if you declare within a block, it makes that block portable." Sure, but then you start coding without thinking, without intentionality, at least to me. That leads to bugs. But if it works for you, good. Last note: one of the other tenets of good programming is "beware of premature optimization." I'd rather do things cleanly (according to myself) and avoid bugs (and waste a cycle or two) then to have bugs. In C++, I work a bit differently, I do declare closer at certain times, especially when I'm using a more "temporarish" variable that is really only used locally. The variable declaration thing has some wiggle room to it, it is categorized under the "label-goto" argument. In other words, "anything in moderation is good." * * * * * * * * * * * * * * * * * * * * * * * * * * * | Garth Hjelte | | Customer Service Representative, President | | Chicken Systems, Inc, Rubber Chicken Software Co. | | 714 5th Street SE | | Willmar, MN 56201 USA | | | | 800-8-PRO-EPS Toll Free Order Line (US Only) | | 320-235-9798 Tech Support, Sampler Questions | | International Line | | 360-838-7689 Fax | | Product Sales: [EMAIL PROTECTED] | | Product Support: [EMAIL PROTECTED] | | Sampler Q+A: [EMAIL PROTECTED] | | Web Page: www.chickensys.com | * * * * * * * * * * * * * * * * * * * * * * * * * * * _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
