quote:Original post by Coward
nahh...
It just increases the chance of bugs, and decreases readabillity...
That's what he was saying, IMO; that the use of enums is more readable than his #define counterexample.
quote:
enum UseOfGrapes {
GrapesUse,
NoGrapesUse
};
enum NoUseOfApples {
NoAppleUse,
AppleUse
};
Yuck. Yuck yuck yuck. There is a time for enums, and a time for variables that are not enums.
If you use enums to explicate every boolean parameter, you will horribly clutter the namespace. Furthermore, booleans are in the language because their meaning is clear; a programmer whose function takes an argument of the form "dont_do_xxx" is following a very very bad form. True == do == yes == positive == successful == etc.
quote:
...now here you can not realy understand the meaning, of a function call, unless you look at the name of the paramenters, or use defs...
If you're not looking at the function parameters to understand a call, you should be. In the case of functions where the use of each argument is not obvious, comments suffice. As shown:
fh =foo->open_serial( "COM1:", // first serial port true, // allow buffering false, // don't convert newlines 128, // the buffer size 50); // the timeout value Obviously I wouldn't do that for every function; but where the argument lists are long and the functions unfamiliar, it increases readability far better than enums could. After all, how would you force the programmer not to mix up the buffer size and the timeout value?
quote:So, enums is your friend, so use them whenever it's possible!
Use enums when you have a predefined list of options, which is either three or more options, or two options and a boolean doesn't make much logical sense.
Don't listen to me. I've had too much coffee.
[edited by - sneftel on July 17, 2002 2:14:00 AM]
