[...]
enum Dodges {
NEAT : 1
FLAWED : 2
BARELY : 3
UNSUCCESS : 4
};
I strongly suggest you try compiling any code that you're going to post
here. This is not the correct syntax for an enum type. I presume
you're trying to specify values for NEAT, FLAWED, et al, but I see no
reason not to just rely on the default values of 0, 1, ....
Unlike your initial code snippet, you're giving names to the cases
rather than just using constants 1, 2, 3, which is an improvement.
enum Dodges d = UNSUCCESS;
>
if (dodge < 1)
d = BARELY;
if (dodge < 0.9)
d = FLAWED;
if (dodge < 0.5)
d = NEAT;
As I recall (I might be mistaken), your original code ignored
the possibility that dodge could be >= 1. (For consistency, I'd
definitely write 1.0 rather than 1 here).
If dodge < 0.5, you test its value 3 times and update the value of d
3 times. The performance impact is trivial, but it's conceptually
more complex than it needs to be. I'd put the (dodge < 0.5) test
first and use an else-if chain. (The fact that this forces the
order of the tests is mildly annoying, I suppose.)
switch (d)
{
case NEAT:
slog("%s easily dodged attack...", being[k].name);
return 1;
case FLAWED:
slog("%s hardly dodged attack...", being[k].name);
return 1;
case BARELY:
slog("%s dodged attack...", being[k].name);
return 1;
default:
return -1; // not dodged.
}
The association between NEAT and "easily", FLAWED and "hardly", and
BARELY and nothing, seems arbitrary. I'd probably give the enumeration
constants names that match the string.
WHERE IS THIS DUPLICATION?
>
WHERE ARE THESE SYNTAX ERRORS YOU NEVER EXPLICITLY STATE?
I don't know whether there were syntax errors in your previous code.
If the syntax errors in your new code were corrected, this might
be a decent demonstration of a useful technique: transforming a
range of floating-point values into discrete values so they can be
operated on more easily. In this particular case, I wouldn't bother.
There are only 3 normal and 1 exceptional cases being considered, and
I personally would prefer to test the floating-point value directly.
If I want to assign names to the ranges, the strings passed to slog()
express that clearly enough, or I might add comments.
if (dodge < 0.5) {
slog("%s dodged attack...", being[k].name);
}
else if (dodge < 0.9) {
slog("%s hardly dodged attack...", being[k].name);
}
else if // ...
In a more complicated case, setting up the enum values could be a
good idea, particularly if those values are going to be used later
in the code. If this is a simple example meant to demonstrate the
technique, that's fine. There's a big difference between writing
code to demonstrate a concept (which often needs to be simplified)
and writing real-world code.
Am I cleared for Heaven now?
>
Can we get ten more people to hop on the bandwagon and RUDELY tell me
how bad it is?
>
I gauged that RUDENESS is something you try to avoid here.
*yawn*
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Les messages affichés proviennent d'usenet.