I agree with you about declarations and not relying on default properties. (I
cringe when I see these violations(?), too.)
But (I think) the cStr() really clutters the code and makes it difficult to
read.
Here's hoping that you come over to the evil side on that part quickly.
ps. One more thing that I cringe when I see--unqualified ranges. That causes
more trouble when code is copy|pasted to a different module/project.
"Rick Rothstein (MVP - VB)" wrote:
>
> > Just a note.
> >
> > VBA is pretty forgiving. You can concatenate text with numbers and still
> > end up
> > with text.
> >
> > .Range("B" & CStr(X))
> > could be written as:
> > .Range("B" & X)
> >
> > (same in the =sum() portion, too.)
> >
> > I like:
> > .cells(x,"B")
> > though.
> >
> > I'm guessing that VB is less forgiving?????
>
> No, actually, the guts of VBA and compiled VB are the same; so, in this
> case, VB would be as forgiving. In the compiled VB world, it is considered
> (and please don't take this the wrong way) poor programming practice to let
> VB handle the conversions automatically when you know in advance what the
> data type should be. Over there, VB's underlying data type coercions are
> called "evil type coercions" and are to be avoided whenever possible. In
> addition, not omitting default object properties (the Value property of a
> Range being an example), expressly declaring variable types and avoiding
> Variants whenever possible are also considered good programming practice as
> well... three more things which seem to be laxly adhered to in the Excel
> community. So, when you see me doing any of these things (such as expressly
> using the CStr function as you pointed out), it will simply be a case of
> "old habits die hard".
>
> Rick
--
Dave Peterson
|