Greg Maxey said:
myArray = Array("A", "B", "C", "D", "E", "F", "G", _
"H", "I", "J", "K", "L", "M", "N", "O", _
"P", "Q", "R", "S", "T", "U", "V", "W", _
"X", "Y", "Z")
Is there a better way?
It depends on what you call "better". If the way you have is "good enough"
then searching for a better way is unnecessary.
But to decide whether you need to search further, we need to define these
terms. As far as I'm concerned, the following definitions are reasonable in
this context.
"good enough"
1. the code achieves the desired result
2. it takes an acceptable amount of time to achieve the desired result and
is efficient in the use of computer resources
3. It is as self-containeed as practical and not unnecessarily dependent on
other code in the program
4. it is reasonably easy to see how the code achieves the result in case you
decide to adapt it to another purpose later.
5. As far as is reasonably foreseeable and practical, it minimizes platform
dependencies and therefore the risk of breaking if moved to a new platform
"better"
1. corrects an incorrect result
2. achieves noticeable improvements in overall execution time or other use
of resources
3. reduces the risk of unexpected interactions with other parts of the
program
4. makes the code easier to read
5. reduces platform dependencies
In the case of this particular code sample, what you have now achieves the
necessary result. I doubt that you are trying to do this repeatedly many
times in a tight loop, so improvements in execution time will be negligable,
it is a small piece of code so resource allogation (e.g. memory) is not
significant. The coede is self-contained, and it is perfectly clear how the
result is being achieved. Therefore your code is good enough.
Of course, there are other ways by which you could do the same thing. Others
have suggested different approaches. I'll add one other.
myArray = Split("A B C D E F G H I J K L M N O P Q R S T U V W X Y Z", " ")
In my opinion, Jezebel's code is less understandable and depends on the fact
that the underlying encoding of strings is ANSI. It might be faster (that
would have to be benchmarked) but it is such a small piece of code that
marginal speed changes are not going to matter in the overall execution time
of your program. But it's better not to to introduce dependencies if you
don't need to. Introducing unnecessary dependencies means that you code has
that much more chance of breaking if and when you have to make use of it on
a different platform, such as a new version of Word, a new version of
Windows, or a non-windows platform.
Jerry's code is also in my view a bit less readable. While it doesn't depend
on the exact ANSI coding, it does assume that the characters A to Z all have
consecutive code values. Of course, that assumption is true for ANSI coding
and also for Unicode, but why run the (albeit remote) risk that somebody
will change it? Also, if you find that you need to adapt your code for other
European languages with additional or accented characters, you will end up
having to change things altogether, rather than just plugging in the
additional characters in their appropriate places in the array, because the
additional characters do not have ANSI codes that are consecutive.
Remember also that even now, character codes for some characters are
different between Word for Windows and Word for Macintosh, so this isn't
quite the hypothetical issue that you might otherwise think. For instance, I
believe that a non-breaking space has a different code on the two platforms.
(I don't have a Mac handy to check this, so I'm going on memory).
From your recent questions, I get the sense that you are engaged in a wholly
laudable attempt to make your code as good as it can be, but I think at
times you are overdoing it and not trusting yourself to accept that it is
"good enough" for your purpose.
