On May 01, 2007, at 20:42 UTC, Brendan Murphy wrote: > Garth Hjelte wrote: > > I'm not sure I agree with this. I think it's fairly possible. > > If I write code that maximizes its readability (without comments), it > will generate slower code. Code that is maximized for optimum object > code generation tends to be ugly to the reader. You simply can't have > it both ways. Better to maximize your code for its intended purpose > and let the comments do their part. Do the experiment yourself and > take a piece of code and maximize it for both ends of the spectrum.
You seem to be contradicting your own statements elsewhere, where you pointed out (correctly) that in most cases, programmer time is worth more that CPU cycles. (I don't think you used exactly that wording, but that was the gist of it, and I certainly agree). Performance optimization is sometimes necessary, but often not where you expect, and certainly not everywhere. The sensible approach is to write clear, maintainable code first, and optimize as needed. (Of course when you have a dozen ways to approach a problem, all equally clear, there's no harm in picking the one that is also efficient.) > People have already stated why they go for this position, but it > really boils down to a matter of perspective. Like I have stated > before in this thread by asking the question what is more expensive? > If you drill down on this question on purely technical basis you > would come to the conclusion you should put the DIM in the block, but > this point of view ignores the big picture. No, it is all about the big picture. > It is more expensive to make the code harder to read. True. > People in this thread have stated that > they think that putting the DIMs all over the place is more readable, > but that is from their point of view it is more readable to them and > this is circular reasoning. No. It is *always* clearer what the code is doing (which is the only sensible meaning of "more readable") if the declarations are block scoped. It is also easier to maintain the code in other important ways (e.g. refactoring). It doesn't matter if I wrote the code, or if I'm reading code written by someone else; as long as they've properly placed the Dim statements, then I gain these benefits. The one exception to this "always" is if the reader is not used to it, in which case I suppose it may cause a mental stumble at first, as when encountering any new idiom. Charles admitted to feeling this effect at first, but has since gotten used to it and now finds himself slowed down when the Dim statements are at the top (as do I). He also pointed out a good psychological reason for this: it requires you to keep more stuff in your mind, for a longer period, as you read the code. A central tenet of managing the complexity of software artifacts is to minimize the amount of stuff you have to keep in mind at once; virtually all good language design choices and coding practices stem from that. > I have given examples why organizing it > in certain patterns is better for the brain to understand, otherwise > in my table of context example books would have a far different look > and feel than they do today and that should tell you something. Variable declarations aren't a table of contents. A header file (in languages that have such) or the code browser (in RB) is more analogous. > Let's say your average method is 50 NCSL, is it not a negligible thing > to move the DIMs to the top? You are in the scope of the method, so > how much closer do you really need to be? As close as they can be, since that helps them clarify the intent of the code. At the top, they mean nothing but "I'm using an integer somewhere in this method for some ill-defined period of time." Declared properly, they mean "I'm using an integer right here, until the end of the block; this is where it matters, and beyond that you can forget about it." > In general there would be no > measurable speed difference where you declared them. Optimizing by > putting the DIMs in blocks is meaningless. Who's claiming this has anything to do with performance optimization? This is about writing clear, maintainable code. > Bottom line, putting your DIMs in the blocks ignores the big picture. No, we do it BECAUSE of the big picture. > Most positions like these are reactionary concepts to > what once was previously done. Just wait, and you will observe this > recycling in action. People like to take positions because it is > different from what is currently done because it gives them a sense > of something new. I prefer to do things because they work. It doesn't work as well as putting them in block scope. My guess is that you prefer to do this just because you've always done it that way; you're still stuck in the "declarations at the top" habit. Try it the other way for a few months, on real, live projects, and I think you'll be pleasantly surprised at how much clearer and more maintainable your code becomes. If 95% of the experienced engineers have moved from practice A to practice B, and you're still using practice A, then one possibility is that 95% of the world are idiots. But the other possibility is that they're not, and know something you haven't yet grasped. Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
