Max,

First, a hearty welcome! You've offered a wonderful essay, and I 
certainly agree with you about the desirability of presenting our best 
work. For the sake of discussion, though, allow me to play devil's 
advocate with regard to some diversity in programming style....

Verbose variable names, etc., can sometimes obscure the structure of a 
program. Just as in verbal communication, there are times when 
sesquipedalian verbiage helps to impart subtlety of nuance, and other 
times when it's better to keep it short and sweet.  I find my eyes 
glazing over when I encounter code with those interminable constant 
names which will fit only 1 or 2 to a line. I recognize they are 
necessary, but I have been known to redefine them as short, memorable 
constants that merely suggest, rather than spell out, their purpose for 
my own use.

When a variable is used for a simple loop counter, it could be 
confusing to a beginner to have it endowed with the name of whatever it 
is counting, as though that gives it some special relationship to what 
it's counting. Using a simple x (or i, or r, or c, or whatever) makes 
it clear that we're using a variable to represent a number, and it's a 
heck of a lot easier to type and to remember.

I rather suspect it may have been the fn I posted last night, with its 
L1's and str2's that motivated your message. Maybe I am a lazy coder. 
If I can save a few keystrokes, I'll do so and take pleasure in it. I 
have certain conventions I use pretty consistently, like x & y for 
coordinates, i or r for counters, L for lengths, s names for strings. 
Knowing that system makes my code very clear without a lot of extra 
typing. I try to add enough commentary to allow myself to see what is 
happening if I come back to it 5 years from now, and to give someone 
else a chance of figuring it out, but I see no point in writing a 
paragraph for each line. I once tried to study a complex program that 
was written that way... Every line of code had anywhere from 1 to 12 
lines of documentation, most of it redundant. Not until I removed most 
of the commentary could I even begin to see how the code worked!

I know that kind of excess isn't what you're proposing, but I'm here to 
suggest that people code different ways for different purposes. I'm a 
hobbyist who often gets more satisfaction from "reinventing the wheel" 
than from searching for existing code I can plug in. I'm much more 
interested in the algorithm or the structure than in the code itself.

Even though I've been accused of it, I'm not advocating cryptic, 
obscure coding (and I've never done any C). There can be differences of 
opinion, though, as to what constitutes adequately clear code. If 
someone has difficulty understanding my code, I'm more than happy to 
offer as much explication as needed, in as much depth as needed, to 
help them learn the principles I'm working from, so the next time they 
encounter such a structure, it will be clearer. This might arguably be 
of more help than self-explanatory code.

Your point is valid and well made, but please don't hate me or 
disparage my code if I tell you that I will never in my life name a 
loop counter "arrayElement" or write a remark to point out that my DIM 
statements are meant to dimension variables. :-) And PLEASE don't let 
my offering another opinion keep you from further writing. This list 
has been starving for some discussion of this sort!

All the best,
  e-e
  =J= a  y
   "

PS. As for rewriting all my code, I suspect I'd do a lot of it the 
same, but without the bugs. :-)

On Wednesday, January 4, 2006, at 11:26  PM, maxclass@... wrote:

> To All,
>
> Just a few thoughts here from the new guy. If you could rewrite all 
> the code you have ever written would you do it differently knowing 
> what you know today? Most of you would probably give a resounding 
> "Yes". The point I'd like to make here is this. Since everyone that 
> reads these posts, from beginners to professionals, learns something 
> from them (including me) I feel that maybe using the best concepts we 
> know of can raise everyones skill level up a notch or two and light up 
> the way for those who are following in our footsteps. Novice users 
> tend to copy examples verbatim along with any bad old style habits 
> when we know that there are better ways to show good programming style 
> and examples. New users learn from what they see here and follow these 
> examples and their programming style, good or bad. Being cryptic and 
> obscure clearly is what "C" was all about and that's why we like using 
> FB. We have the ability to show great examples of the best ways to use 
> the tools we have at our disposal. Should we choose not to do so is 
> just being plain lazy when nothing more than a few extra keystrokes 
> and a little fore thought results in code that will last a lifetime 
> instead of being a one-night stand.
>
> Writing code that was not dynamic, when I had the chance, has probably 
> cost me more down time in the long run than any single thing I have 
> ever done code wise. Beginners don't always see it that way at first 
> so they have to learn the hard way. No one is perfect either, but if 
> we try our best to use well coded examples, even for small examples, 
> they will always stand the test of time. Even those who do not need 
> the examples see them and learn from them, good or bad.
>
> I realize that the point of code like the code below was to get the 
> point across and it does that job fine. I have no basic problem with 
> the code example given, it works, and I realize it was only 
> implemented to be an example of how to accomplish a specific task. I 
> sincerely do not wish to offend anyones code example here and this is 
> not meant to do that, but, a possible example of teaching good style, 
> as I see it, might be to start with something like the following and 
> then expand from there as needed. We are no longer bound by two letter 
> variables like the old days. Let's let the code tell us and everybody 
> else what it is doing. There are no losers when we do so.
>
>> ===== Example =============
>> dim gtotals(10) as double
>> dim x
>>
>> for x = 1 to 10
>>   print using "###.##  "; gtotals(x);
>> next x :print
>> ==========================
>
> becomes something like
>
> /* Setup an initial number of Array Elements
>     first using a constant. */
>
> _maxArrayElements = 10
>
> /* Dimension your variables next */
>
> dim gTotals( _maxArrayElements ) as double
> dim arrayElement as long
>
> /* Example code */
> ...
> for arrayElement = 1 to _maxArrayElements
>  print using "###.##"; gTotals( arrayElement )
> next arrayElement
>
> etc,
>
> Using good examples like "sizeof( double )" was a perfect example of 
> doing it right the first time. Not only does it say what it is doing 
> but it is also machine independent. Beginners take note. There is a 
> valuable lesson here.
>
> A novice might not program like this but they might be very interested 
> to see the benefits of using something as simple as this to make their 
> programming life easier, especially when they decide that they would 
> like to change _maxArrayElements to be 100, or 1000 or any other 
> number without having to change more than the number in one line of 
> code.
>
> Many of us started with systems with very little expensive memory 
> (mine was a TRS-80 w/4k of ram). We did not have constants and could 
> only use two letter variables. Lucky for us times have changed and we 
> can afford to write very meaningful code so why not. Beginners will 
> follow our examples. I only wish I had had such a coach when I started 
> out so I didn't have to learn things the hard way. Someone earlier 
> mentioned taking the time to think out and plan something before 
> diving in head first in response to some ones post. Sort of like the 
> old "ounce of prevention" thing. Years from now these examples will 
> still be here for others to see. I for one, think we will all benefit 
> by showing what we think is our best examples for everyone to see and 
> learn from. All code is a work of art, especially when it works 
> flawlessly. This is the museum where WE put our artwork on display for 
> the whole world to see.
>
> Thank you for your time,
>
> Max Taylor
> The MaxClass Guy
>
> --
>