Well, if I wasn't due for a 'chain yanking',
then I'm just paid ahead now. <g

--------------------------

Best Regards, Charlie

Ron
Microsoft MVP (Excel)
(XL2003, Win XP)




"Charlie" wrote in message
...
I was mostly just pulling your chain. :)

Yes, I do use Option Explicit, loops such as...
For iRow = iStartRow to iEndRow Step iRowIncr
...and I almost never use hardcoded range references (except as examples).
I primarily use named ranges.

Small loops such as...
For i = 1 To 10
...are fine for a few lines of code. I've never written 400 lines of code
in one sub or function. That's taboo. Either I'm doing something wrong
or I
need to break it up into smaller tasks.

Error trapping, on the other hand, is another subject. After 28 years of
programming mostly engineering apps I've found it necessary to invoke the
"Law of Diminishing Returns": The more time I spend writing
error-trapping
code the less time I have for problem solving. Most of the time if (when)
an
error is trapped I need to debug something, thereby rendering the
error-trapping code obsolete. So I pick and choose those places needing
error trapping carefully.

Funny story regarding your mention of "400 lines down": Eleven years ago
at
my last company I was asked to look at someone's VAX Basic (not VB)
program
after he had left. It was on the order of 19,000 lines of code! Yes,
19,000... with No comments and No subroutine calls! Sections of code
being
reused were cut and pasted appropriately rather than put into a sub or
function. Unbelievable!

Needless to say I declined to "add some features" to the program.

"Ron Coderre" wrote:

Hi, Charlie

I *did* say that I wasn't criticizing anybody
in particular...and I'm still not.

However, since this is a peer-help newsgroup, I feel it's important
to be as instructional as possible. People are reading what we
suggest and may be assuming that all pertinent information is being
provided and that the code offered is "professional".

So....
Undeclared variables:
I don't know that the variables weren't declared and neither
does anyone else....but being an experienced programmer I *know*
that they should be. It's easy enough to just declare them to
avoid any ambiguity...or..even better..include Option Explicit
at the top of the module to force variable declarations. It
may not matter for a 10 line program, but we develop our coding
habits when learning to build small programs. As the code gets
more complex, undeclared variables can be a nightmare to debug.
Especially when typos find their way into the code:
iStart vs iStrt vs iStrat

Cryptic variables:
400 lines down in the code you see:
For x = y to z Step j
For a = b to c

IMHO...that's a habit that comes from taking programming courses,
where all that matters is compilation and execution and no thought is
given to code maintenance or transfer of code ownership.

If I inherited somebody else's code, I would certainly prefer to see:
For iRowCtr = iStartRow to iEndRow Step iRowIncr
For EmpCtr = StartEmp to EndEmp

An added benefit is that I could search the project for instances
of "StartEmp"...searching for "b" would be impractical.

Hardcoded references:
They have their place....but, best practice is to avoid them.
Then, if the ref changes you don't have to scour the code to find all
the instances to edit. It was a general commment, not a critique.
Specific circumstances dictate usage.

Unnecessary range selections:
You had a question about the difference between SELECT and ACTIVATE.
Type this in the Immediate Window: Range("z5").Activate
now try: Range("z5").Select
Both versions *select* cell Z5 on the active sheet.

Error Traps:
Generally a good practice. Regarding the post, though, we are
building a long list. It's possible the sheet may be protected
or the list is to start near the bottom of the sheet with not enough
cells to complete the list.

Thanks for your comments.

--------------------------

Regards,

Ron
Microsoft MVP (Excel)
(XL2003, Win XP)



"Charlie" wrote in message
...
Below:

"Ron Coderre" wrote:

Not to pick on anybody in particular, but
I cringe when I see code with:
- Undeclared variables

How do you know they were undeclared? The code submitted was a
"snippet."
I figured readers could declare (or not) their own variables.

- Cryptic variables (declared or not)

i, j, k, real cryptic for loop counters. Long Live "For i = 1 To 10"

- Hardcoded references

if you're referring to Range("A1"), once again, snippet (example). At
least
according to the OP's request it will work, whereas Selection.Cells(1,
1)
might not.

- Unnecessary range selections

you may win on this one. FTR, I didn't select the cells I activated
them.
Maybe you can explain the difference. I don't know the answer to this
one.

- and no error traps if there's a risk of crashing

how do you know there wasn't an error trap set? Snippet, remember?
Let
me
go back and review the snippet for a "risk of crashing"... Nope, I see
none.

But thanks for the critique. :)


--------------------------

Regards,

Ron
Microsoft MVP (Excel)
(XL2003, Win XP)


"Charlie" wrote in message
...
Several slick methods here. I thought yours was the simplest,
cleanest.
I
shortened it even more and it ran in about one second.

Application.ScreenUpdating = False
Range("A1").Activate

For i = 65 To 90
For j = 65 To 90
For k = 65 To 90
ActiveCell = Chr(i) & Chr(j) & Chr(k)
ActiveCell.Offset(1, 0).Activate
Next k
Next j
Next i

Application.ScreenUpdating = True


"Gary''s Student" wrote:

Sub ThreeLetter()
l = 1
For i = 65 To 90
x = Chr(i)
For j = 65 To 90
y = Chr(j)
For k = 65 To 90
z = Chr(k)
Cells(l, 1).Value = x & y & z
l = l + 1
Next
Next
Next
End Sub

--
Gary''s Student - gsnu200777