Brendan Murphy wrote: > Glenn L. Austin wrote: >> 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. > > That is your opinion and not necessarily a tenet of good software > design. > > Reading code is similar to reading a book.
This is the source of your misunderstanding. Reading code is NOT like reading a book. They're vastly different. If you want code to be easily read and maintained, then it is going to come down to the following principles: 1. Consistent Coding Conventions 2. Proper Pre-planning and Pre-development 3. Organized Team Development 4. Self-documenting code when possible, informative comments otherwise. The placement of your DIM statements are a matter of opinion, however I will say that placing the Dim statements closest to where the variable is used can be a huge factor when refactoring the application, as previously stated. People need to remember that there are different coding styles for different purposes. For instance, if you need to code in a way that maintains REALbasic compiler compatibility, then something like Dim placement is important to consider, as would usage of language features not supported by the compiler. The broad statement that "good" coding means putting your Dims at the top is just plain false. If you believe you can make that claim, let's see some solid evidence to support your claim. I will agree that most people (developers) don't know how to code very well, but that is probably because most of the time is spent on the mechanics of development, not the future of the code-base. Most developers just start coding their project, and thinking it up on the fly, whereas some developers spend much time planning a project for a well-organized architecture. Which one is better might depend on the goals of the project. ...I've probably said enough for now, I could write a book on this if I'm not careful. - Ryan Dary If you bury your DIM > statements, you make it harder to read. Knowing where your > declarations are makes it easier to understand the code. If a book > had its table of contents randomly spread throughout the chapters, > the result would be confusion. If your eye has to scan the code to > find the declaration, you have wasted your time. Knowing where > your DIM statements are speeds your comprehension rate up. > > The big problem is programmers are selfish. This means they write > code that looks good to them for their own consumption and not for > other people to read. They are not thinking of how it will read to > others. Scattering your DIMs is not doing others who read your > code a favor. The number one time waster is trying to understand > code that someone else has written. This FAR outweighs the the > refactoring argument you use. Readability means the code is > understood faster which makes it easier to refactor! > > Gathering all your DIMs in one spot is just one way to make your > code more readable, but there are even bigger fish to fry in > the maintenance of code. Far better is to thoroughly comment your > code which tells the reader what it does. Having to expend time to > figure out what each line of code does, is a huge waste of time. > Most likely, if you are a person who scatters your DIM statements, > then you probably don't comment your code which speaks to the lack > of attention to detail which I mentioned earlier and this is > selfishness (you are not considering others who will use your > code). > > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives: > <http://support.realsoftware.com/listarchives/lists.html> > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
