-=> Quoting Asher Densmore-Lynn to Darin Mcbride
 DM> Yech.  No, this feature was added exactly FOR readability.  By placing
 DM> variables close to code, it makes both easier to understand.  The
 DM> human mind can only keep track of 7 +/- 2 things at a time.  By
 DM> putting all 537 variables at the top of your function, you make it
 DM> hard to follow.  However, by putting the variables close to where
 DM> they're used, the reader is more likely to be able to understand what
 DM> a variable's job is because there is less to remember at a time.
 AD> Excuse me, but the human mind can only keep track of 7 +/- 2 things at
 AD> a time. What the heck are -you- doing with a function with 537
 AD> variables?!
A function that, in version 1, needed maybe 10 lines, but as features were
added, in version 5 it's now 5000 lines?  ;-)
I used 537 merely as a "large number".  10 to 15, your suggestion, is still
too many to keep track of at a time.  By being able to declare them where
they're used, the reader is more likely to be able to remember the relevant
variables, and more likely to forget the irrelevant variables.
 AD>> Think your functions through before you set hand to keyboard --
 AD>> you really should know the vars you'll need before you do
 AD>> anything more than prototype it.
 
 DM> Except when debugging...
 AD> I generally debug -after- I prototype, myself. If you're that good, I
 AD> know a couple of local companies that'd -love- to have you. d: (:
When I'm debugging, I often need:
char szBuf[128];
sprintf(szBuf, "...", ...);
WinMessageBox(HWND_DESKTOP, szBuf, "function name", MB_OK, ...)
(I can't remember offhand...)
I'm apt to forget the szBuf declaration if it's not local to the
WinMessageBox call!
... Reality-ometer:  [\........]  Hmmph!  Thought so...
--- FastEcho 1.46
---------------