On 1-May-07, at 9:12 AM, Glenn L. Austin wrote: > On May 1, 2007, at 7:50 AM, Brendan Murphy 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 >> statements within your code you make your code harder to read. >> Which is more important, your time as a developer or some >> negligible benefit? If your time is only worth $1 an hour, then >> have at it an write unmaintainable code, but the professional >> developers typically earns $50 or more an hour and making your >> code harder to read is rather short sighted. > > 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. If you > can scope the variables inside of a block so that they aren't > available outside of the scope of the block is even better.
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. Having this makes it easier to be careful but it's not impossible to do when you put them all at the top of a routine. There are tons of lines of Cobol that would dispute your claim that it's a basic tenet. It's a current tenet of good design but has not always been one. > 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. However, if the declaration is at the top of the routine > "with all of the others", then you have to go through multiple steps > to refactor the code (move the code then move the declaration). > Heaven help you if you happen to "reuse" one of those variables > within the same routine -- that is arguably the biggest cause of > "unintended features" (e.g. "bugs") in code. I have one piece of code that I maintain that runs in 5.5.5 through 2007 While I'd like to see everyone upgrade to later versions of RB, that's not something I can thrust upon the users of this code base I'm not sure if Brendan is in the same situation, but if you do have RB source that has to be maintained in multiple versions then this is definitely a must do. With new code, where I know it is not going to be used in older versions I do tend to put dim's where they are used to get the benefit the compiler can offer to help me make sure I am not using variables outside their intended scope. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
