Comment On Enumerating The Possibilities

Bagsy first post!



Brillant, a way of embedding comments in variable names...



public static int isTrueReturnsTrueIfTheArgumentIsTrueAndFalseIfItIsNotTrue( boolean t){

    anyone?



}



J

Did the language not have constants, either?

Well, it's not a great idea if you ever have statuses other than 0, 1, and 2, though I'm not really sure it's as bad as many WTF's.  At least it's clear, and presumably will work.  It's kind of cute.

Anonymous:

It's kind of cute.

Consider yourself fired.

Anonymous:

Bagsy first post!

Brillant, a way of embedding comments in variable names...

public static int isTrueReturnsTrueIfTheArgumentIsTrueAndFalseIfItIsNotTrue( boolean t){
    anyone?

}

J

WTF -- Will the real JohnO please stand up?

Very clever.  Helluva lot better than something like  "st as int". 

Cute?? Does this code look cute:

TPSReport.Report_Number_is_a_7_digit_number = '0204561';

TPSReport.Project_Number_is_a_5_digit_number = '65688';

TPSReport.Status__0_new_1_open_2_closed = 2;

 

Personally I'd had to type out all object attributes that way. It's a hell of a lot easier to remember [object].Status" rather than "[object].Status__0...um what were the enumerated options again?" Then again people have gotten lazy with the point-and-click programming environments. Even so, code like that above is just plain ugly and cumberson.

Manni:

Personally I'd had to type out...

*hate to type out

And while I'm making corrections, is anyone else bothered by having variables like "Report_Number" and "Project_Number" set up as fixed-length strings? Do you think they should be... hrm, I dunno.. numeric variables of some sort? As soon as they encounter a 6-digit project number, the code will blow up. I hear they have variable types now that can hold 6 digits, 7, 8, or even more if you pay for the upgrade.

Manni:

Manni:

Personally I'd had to type out...

*hate to type out

And while I'm making corrections, is anyone else bothered by having
variables like "Report_Number" and "Project_Number" set up as
fixed-length strings? Do you think they should be... hrm, I dunno..
numeric variables of some sort? As soon as they encounter a 6-digit
project number, the code will blow up. I hear they have variable types
now that can hold 6 digits, 7, 8, or even more if you pay for the
upgrade.

Yes, but what if their report "number" was : "E790-A" and their project number was "7M3-TMJ" ?

Alex Papadimoulis:

(Note: The submitter requested that not only the submission be anonymized, but the original programming language as well, since it was a rather obscure platform)

like FOCUS (tm)?

Speaking of which, do any languages do Enum's properly? I've been using them in C# (and read how wonderful they were and better than Java blah blah) and noticed that there is no compile time guarantee that an enum type will always be constrained to the declared values because some joker can always cast a bogus int to that type and pass it to my method. This way my major beef with the Java version which used the private constructor and the static instances to restrict - some joker could pass my method a null instead.

Didn't that language even have comments so they could have just written a comment what different values mean?

Manni:

*hate to type out

And while I'm making corrections, is anyone else bothered by having
variables like "Report_Number" and "Project_Number" set up as
fixed-length strings? Do you think they should be... hrm, I dunno..
numeric variables of some sort? As soon as they encounter a 6-digit
project number, the code will blow up. I hear they have variable types
now that can hold 6 digits, 7, 8, or even more if you pay for the
upgrade.

I don't think you can make that call without knowing what the specs
are.  It's possible the report number could contain non-digit
characters, such as 'A1234'?

md2perpe:

Didn't that language even have comments so they
could have just written a comment what different values mean?

No! Because comments are evil!

Mike:

I don't think you can make that call without knowing what the specs are.  It's possible the report number could contain non-digit characters, such as 'A1234'?

Then it's not a number, and the name "Report_Number" is misleading for that attribute. I try to name my variables and such so that if someone else has to look at my code, they know what they should be dealing with (as much as possible). Now that I think about it, after noticing "Status__0_..." as his naming scheme, I'd assume that the name of the variable is probably not going to help me figure out what it's storing.

Only if you trust the code comments more than the code itself. 
Ideally, you would be able to read the code just as well as reading the
comments for the code, and both would be intuitive.



Of course, we all know what reality is like.

Mike R:

Manni:

And while I'm making corrections, is anyone else bothered by having
variables like "Report_Number" and "Project_Number" set up as
fixed-length strings? Do you think they should be... hrm, I dunno..
numeric variables of some sort? As soon as they encounter a 6-digit
project number, the code will blow up. I hear they have variable types
now that can hold 6 digits, 7, 8, or even more if you pay for the
upgrade.

Yes, but what if their report "number" was : "E790-A" and their project number was "7M3-TMJ" ?

And if they allowed eight characters, then they could have "numbers" like "528-9983".



What is *your* phone string?



Sincerely,



Gene Wirchenko

Manni:

Then it's not a number, and the name
"Report_Number" is misleading for that attribute. I try to name my
variables and such so that if someone else has to look at my code, they
know what they should be dealing with (as much as possible). Now that I
think about it, after noticing "Status__0_..." as his naming scheme,
I'd assume that the name of the variable is probably not going to help
me figure out what it's storing.

Funny enough, your Social Security Number is not a number either, and neither is my Social Insurance Number.



Have an unnecessarily literal day, folks

OneFactor:

Speaking of which, do any languages do Enum's
properly? I've been using them in C# (and read how wonderful they were
and better than Java blah blah) and noticed that there is no compile
time guarantee that an enum type will always be constrained to the
declared values because some joker can always cast a
bogus int to that type and pass it to my method. This way my major
beef with the Java version which used the private constructor and the
static instances to restrict - some joker could pass my
method a null instead.

Maybe this is to make C# more C++ like?



From "The C++ Programming Language Third Edition":

Bjarne Stroustrup:

"However, bit-manipulation examples
that require values outside the set of enumerators to be well-defined
have a long history in C and C++."

While this is dumb I don't think it really is up to the level of a wtf



captcha: business

Mike R:

md2perpe:

Didn't that language even have comments so they could have just written a comment what different values mean?

No! Because comments are evil!

 

That's the biggest kind of crap I've heard, no, read, in a while to be honest.

Luffy:

OneFactor:

Speaking of which, do any languages do Enum's properly? I've been using them in C# (and read how wonderful they were and better than Java blah blah) and noticed that there is no compile time guarantee that an enum type will always be constrained to the declared values because some joker can always cast a bogus int to that type and pass it to my method. This way my major beef with the Java version which used the private constructor and the static instances to restrict - some joker could pass my method a null instead.

Maybe this is to make C# more C++ like?

From "The C++ Programming Language Third Edition":

Bjarne Stroustrup:

"However, bit-manipulation examples that require values outside the set of enumerators to be well-defined have a long history in C and C++."

Oh, so this is to allow something like enum FontStyle { bold=1, italic = 2, strikethrough = 4}
and then you can start doing stuff like widget.CommentFontStyle = FontStyle.bold | FontStyle.italic

Wonder if there is a need/demand for a stricter set of enums....

Where's the cover sheet? You are aware that we're using a new cover
sheet on all the TPS reports we send out, right? Did you get the memo?

Speaking of which, do any languages do Enum's properly? I've been using them in C# (and read how wonderful they were and better than Java blah blah) and noticed that there is no compile time guarantee that an enum type will always be constrained to the declared values because some joker can always cast a bogus int to that type and pass it to my method.

I know with recent versions of gcc you can have it generate a compile time warning with C, C++, and Objective-C when this is the case. The problem is that you sometimes need to do this. For example, I was writing a plugin, and had to make it work with a newer version of the application than the SDK that was publicly available. The developers that make the host app supplied me with the couple of enumerated values I needed to do so, even though the new SDK wasn't ready for the public. My customers appreciated that they could upgrade the host app and use some new functionality without waiting until the official SDK was released.

Manni:

And while I'm making corrections, is anyone else bothered by having variables like "Report_Number" and "Project_Number" set up as fixed-length strings? Do you think they should be... hrm, I dunno.. numeric variables of some sort? As soon as they encounter a 6-digit project number, the code will blow up. I hear they have variable types now that can hold 6 digits, 7, 8, or even more if you pay for the upgrade.

I personal despise the underscore in any variable in any location.  I especially dislike the underscore when used to signify member variables.  To your point perhaps if they were going to fixed string lengths the field name would have been better ProjectCode instead of Project_Number?

JohnO:

Anonymous:

Bagsy first post!

*cut*

}

J

WTF -- Will the real JohnO please stand up?

Well I'm the unregistered version, I expire in 30 days unless you give
Microsoft lots of money.  So the board allows unregistered users
to post with registered usernames...

OneFactor:

Luffy:

OneFactor:

Speaking of which, do any languages do Enum's
properly? I've been using them in C# (and read how wonderful they were
and better than Java blah blah) and noticed that there is no compile
time guarantee that an enum type will always be constrained to the
declared values because some joker can always cast a
bogus int to that type and pass it to my method. This way my major
beef with the Java version which used the private constructor and the
static instances to restrict - some joker could pass my
method a null instead.

Maybe this is to make C# more C++ like?

From "The C++ Programming Language Third Edition":

Bjarne Stroustrup:

"However, bit-manipulation examples that
require values outside the set of enumerators to be well-defined have a
long history in C and C++."

Oh, so this is to allow something like enum FontStyle { bold=1, italic = 2, strikethrough = 4}
and then you can start doing stuff like widget.CommentFontStyle = FontStyle.bold | FontStyle.italic

Wonder if there is a need/demand for a stricter set of enums....

Actually, there is an attribute one can set on an enum to indicate they
can be or'ed togethr in that fashion. Just have [Flags()] before the
enum declaration.

Manni:

It's a hell of a lot easier to remember
[object].Status" rather than "[object].Status__0...um what were the
enumerated options again?" Then again people have gotten lazy with the
point-and-click programming environments.

I'll bet you had to walk to school.  Uphill.  Both ways.

OneFactor:

This way my major beef with the Java version
which used the private constructor and the static instances to restrict
- some joker could pass my method a null instead.

That "typesafe enum pattern" was what Java programmers were advised to
use before Java got real enums with 1.5 - but everyone used plain ints
instead since that was done all over the standard API too, and the
typesafe enums required a LOT of work to get right if you wanted to
have them serializable.



But concerning you complaint, that's not "fixed" with the real enums,
and I actually think it's not really valid. When you deal with objects
in Java, a null value is ALWAYS possible, there's no way around it
other than making enums a primitive type, which would require major
changes to the VM.



At least it's only a single "unexpected" value you have to test for...

One language in which enums are particularly well handled is VHDL.... although that's probably not the kind of language you meant.

On the other hand, the synthesizers that process VHDL can not enforce the language constraints on enums, which leads to the ever enjoyable simulation/synthesis mismatch.

OneFactor:

This way my major beef with the Java version
which used the private constructor and the static instances to restrict
- some joker could pass my method a null instead.

I despise Java for any number of reasons (if it weren't for any number of misguided attempts to standardize on Java as the corporate programming language, I'd merely find it distasteful) but a solution to your problem does present itself to me. Just define null as one of the possible values of the enum and give it a meaning.

Anonymous:

Manni:

...

I'll bet you had to walk to school.  Uphill.  Both ways.

In the snow. All year round. Without shoes. Carrying my crippled little brother under one arm. Times have changed since the late 80's/early 90's.

Anonymous:

Manni:

...

Funny enough, your Social Security Number is not a number either, and neither is my Social Insurance Number.

Have an unnecessarily literal day, folks

OK I'll entertain this one, even though I know you're being argumentative and playing devil's advocate...

Actually yes, my SSN is a number. The hyphens are separators. You can take out the hyphens and still have a valid SSN. The same is true for phone numbers. (123) 456-7890 is the same as 1234567890 (I can't seem to find the dash button on my phone).

The difference is that if you take out the separators, you still have the original value, and voila it's a valid number. If you try taking out the non-numeric values from "A3D-TRC", you clearly will lose almost all valid data.

If it were me coding this and the project "number" could have non-numerics in it, I'd call it ProjectCode as previously suggested, or ProjectID or something. Quit being a naysayer and just accept that having "number" in the name of a string variable is misleading.

Speaking of taking things literally...

"I wanna see a forklift lift a crate of forks...it would be so damn literal for me!" -Mitch Hedberg

Everyone seems to be missing the point here.  Embedding the
acceptable values in a variable is a stupid solution to the lack of an
enum type.  Even a comment above the declaration is not that
great, since you still have magic numbers floating around in the code
which have to be manually changed if the acceptable values change.



All an enum is (in C-like languages, anyway) is an integer with a bunch
of constants.  If the langage has integers, you can make
enums.  The real solution is something like:

    Status as int

    Status_new = 0 as constant int

    Status_open = 1 as constant int

    Status_closed = 2 as constant int



(substitute with the equivalent syntax in the target language, of course.)

Manni:

If it were me coding this and the project
"number" could have non-numerics in it, I'd call it ProjectCode as
previously suggested, or ProjectID or something. Quit being a naysayer
and just accept that having "number" in the name of a string
variable is misleading.

And we'll let you have a good time finding the location to fix when the
users complain about something to do with the project number. They will
call it a project number, you know, no matter how few numeric
characters are involved in expressing the value. And that "project
number" may be something completely different from the project code or
the project ID (both of which may also be present).



And no, your SSN is not a number, even if systems designed to accept it
as a datum treat is as such. The hyphens ARE a part of the "number", as
are the spaces in a  Canadian SIN. A telephone number is probably
the worst example to bring up in this regard, since the separator is
not entirely arbitrary. In the US number 1-212-555-1212, the 1
indicates a billed direct dialing option for long distance, the 212 is
an area code, the 555 is a switching group (or exchange) and the final
four are the local number. Only the final four are always required for
a direct connection. The last number of the exchange group is usually
required for in-exchange connections, although newer swithing systems
need the whole exchange. The full exchange group is always required for
out-of-exchange connections within the same area code, and may need to
be prefaced with a long distance connection option (1 or 0) if the
connection is long distance. The area code is required for out-of-area
connections (and, more recently, in 10-digit urban zones). Again, the 1
or 0 prefix may or may not be required, since not all 10-digit numbers
are long distance. It is most definitely NOT just a number with
mnemonic aids embedded.

Anonymous:

Well, it's not a great idea if you
ever have statuses other than 0, 1, and 2

Language polymorphism
allows you to change types without necessarily needing to change the
code.  Hungarian Notation sabotages that by encoding type
information into the variable name.  You can't change types
without either (1) having to change all variable names to match or (2)
leaving things inconsistent, which makes the notation pointless.



This is similar but (IMHO) worse.  It encodes type domain
information into the type name.  As you point out, you now can't
add or remove status codes without having to either (1) change the type
name everywhere it appears or (2) become inconsistent, making it
pointless.

Stan Rogers:

<a lot>

And no, your SSN is not a number, even if systems designed to accept it as a datum treat is as such. The hyphens ARE a part of the "number", as are the spaces in a  Canadian SIN. A telephone number is probably the worst example to bring up in this regard, since the separator is not entirely arbitrary. In the US number 1-212-555-1212, the 1 indicates a billed direct dialing option for long distance, the 212 is an area code, the 555 is a switching group (or exchange) and the final four are the local number. Only the final four are always required for a direct connection. The last number of the exchange group is usually required for in-exchange connections, although newer swithing systems need the whole exchange. The full exchange group is always required for out-of-exchange connections within the same area code, and may need to be prefaced with a long distance connection option (1 or 0) if the connection is long distance. The area code is required for out-of-area connections (and, more recently, in 10-digit urban zones). Again, the 1 or 0 prefix may or may not be required, since not all 10-digit numbers are long distance. It is most definitely NOT just a number with mnemonic aids embedded.

Stan I'll keep my reply simple. First off, why would you create variable names based on what the users call it? Code is supposed to be intuitive to PROGRAMMERS, not USERS.

And secondly, you're missing the point with my SSN/phone number example. I'm saying that they are numbers because even if you took out the separators, you still have your data. The hyphens are for formatting, used for breaking up the data into meaningful chunks. As I said before, do you have a hyphen button on your phone? My guess is that you punch in the numbers as if the hyphens weren't there.

This is a pointless argument because the real WTF is that you don't put the possible enumerated values as the name of your variable. The rest of this number/string variable naming crap is just personal preference.

And we'll let you have a good time finding the location to fix when the
users complain about something to do with the project number. They will
call it a project number, you know, no matter how few numeric
characters are involved in expressing the value. And that "project
number" may be something completely different from the project code or
the project ID (both of which may also be present).

You beat me to this response.



It's difficult enough to get "proper development practices" to affect SOP in the development department.  I can't imagine how monumentally futile it would be to attempt to get "proper development practices" to affect SOP in other departments.



Yikes.  I don't want that job, Manni can have it if he wants it. ;)

Mike R:

md2perpe:

Didn't that language even have comments so they
could have just written a comment what different values mean?

No! Because comments are evil!

This reminds me of a quote I had on the white board for nearly a year:



"If the code and the comments disagree, both are probably wrong."



Of course this implies there actually ARE comments...



Fabian

Manni:

First off, why would you create variable names based
on what the users call it? Code is supposed to be intuitive to
PROGRAMMERS, not USERS.

Programmers need to interact with users, even if indirectly. 
These aren't two separate worlds here.  The concept that they are
is one of the biggest sources of the proliferation of "unfriendly"
software and "usability bugs".  How do you bridge the divide in
this ideal world of yours?  Do you
want to be the one that maintains the lookup document housing the
translation between the users' terminology and the program's
terminology?  I've worked on enough systems to know that the
trouble this causes is not usually worth it.  I do my best,
instead, to make sure that I use the appropriate data types, and rely
on those to tip me off as to the nature of the data.  They are
what make the final decision on what can be stored, anyway.



Programs don't exist in a vacuum.  They exist to get a job
done.  In many cases they exist as part of a larger system already
in place, or to facilitate a job done by a user.  There is a
context in which each program resides, and which can't be ignored in
the design or implementation of the program just because the coder
doesn't like the existing terminology.  Attempting to affect
change at this level is a little like trying to earth-quake-proof a
high-rise starting at the penthouse: while the result may be
technically correct at that level, the effort is totally ineffective
given the context of the bigger picture, and may even serve to make the
whole thing more fragile.

Manni:

This is a pointless argument
because the real WTF is that you don't put the possible enumerated
values as the name of your variable. The rest of this number/string
variable naming crap is just personal preference.

If we always stayed 100% on-topic at all times on all discussion boards, there would be very few interesting discussions.

OneFactor:

Speaking of which, do any languages do Enum's
properly? I've been using them in C# (and read how wonderful they were
and better than Java blah blah) and noticed that there is no compile
time guarantee that an enum type will always be constrained to the
declared values because some joker can always cast a
bogus int to that type and pass it to my method. This way my major
beef with the Java version which used the private constructor and the
static instances to restrict - some joker could pass my
method a null instead.

There aren't a lot of joker-proof languages, but I think Haskell matches your criterium.

Alex Papadimoulis:

define datastruct TPSReport as

(

  Report_Number as fixedstring[7],
  Project_Number as fixedstring[5],
  Status__0_new_1_open_2_closed as int

  % ED: Snip ...

)

Hmmm... On the one hand, it's definitely a curious perversion, os (by
definition) a WTF. On the other hand, it might be a clever trick to
make sure other programmers at least know
how to use the status field. If it was simply "Status as int" and some
constants "Status_new as int = 0" defined elsewhere, those who are too
lazy to RTFM would probably use it incorrectly or ask stupid questions.
If the IDE helps with auto-completion, who cares about the long name?
Should there ever be a forth value for status, it would require lots of
work anyway, like fixing the existing database and handling the new status; replacing all
occurences of Status__0_new_1_open_2_closed with Status__0_new_1_open_2_closed_3_dunno would be the easiest task.

Oh my god, it's Bob!



Greeeeat singer, Michael Bolton. eh-eh-eh, yeah, really like him, too.



:-)

Mike R:

No! Because comments are evil!

I'd rather say that dogmatism is evil. The way to read comments is as
an aid that helps you understand what the code is meant to do. If
comment and code don't agree, the code always wins. It's like
annotations to a mathematical proof - no serious mathematician would
take them for gospel, but they help him/her understand what the author
was thinking, and (s)he will thus be more easily able to see any logical flaws and contradictions than if the proof had not been commented.

Anonymous:

Funny enough, your Social Security Number is
not a number either, and neither is my Social Insurance Number.



Have an unnecessarily literal day, folks

These are irritating conventions, but shouldn't a programmer know better than this?

OneFactor:

Speaking of which, do any languages do Enum's
properly? I've been using them in C# (and read how wonderful they were
and better than Java blah blah) and noticed that there is no compile
time guarantee that an enum type will always be constrained to the
declared values because some joker can always cast a
bogus int to that type and pass it to my method. This way my major
beef with the Java version which used the private constructor and the
static instances to restrict - some joker could pass my
method a null instead.

Someone pointed out VHDL, but since this is more a HDL than a
general-purpose programming language, I should mention Ada (upon which
VHDL is based). In Ada enumeration types work (IMHO) as they should,
i.e. they are real types so that there will be no confusion between
enumeration values Orage and Orange for example when one of them
belongs to type Fruits and the other to types Colors.



Furthermore other language constructs (like case statement)
automatically checks that every possible enumeration has an action for
it. You can also define the representation for the enumerations
portably. And to top it off, as with other types enumeration types have
attributes First, Last, Pred, Succ, and Range defined for them.

Mike R:

No! Because comments are evil!

It just occurred to me that this applies to "self-documenting code" as
well. What if I name a variable "peopleCounter", and it, in effect,
counts tennis balls instead? Horrible! So let's just name all variables
i, j, k, ii, ij ... likewise, functions should be named f, g, h, ff ...



No, wait! What if some crazed freak names his variable "f", and I
mistake it to be a function? Confusing! Let's use the same naming (or is it numbering?) conventions for variables, functions, classes etc.

Manni:

Actually yes, my SSN is a number. The hyphens are separators. You can take out the hyphens and still have a valid SSN.

My SSN starts with two zeros. If you take out the hyphens and put the value into a numeric variable, you will lose information.



Same with ZIP codes in north eastern US that start with 0. Now these
are called "codes", but I've seen plenty of folks try to put this data
into a numeric field in a database and then have complicated logic in
the printing routines to add the leading 0 back on. That's what I call
the "numb-er" approach, as in "more NUMB"!



My rule of thumb has been, if it's called a number, but no math is done
on it, put it in a character field with a width two or more greater
than you think will ever be necessary. For example a client "number"
field in a system where you only expect under 1000 clients should go in
a character field of width 6 and start off with a value of "100001" and
increase from there.



Another reason the SSN is not "a" number is that each group of digits
has a distinct meaning. It's not just one specific value in sequence.
Yeah it might have been better if they called it a "code", but most
folks can handle having multiple meanings for one word so "number"
doesn't always have to mean a "mathematical value". It also means a
song or a joint for example.

Manni:

...The hyphens are for formatting, used for breaking up the
data into meaningful chunks. As I said before, do you have a hyphen
button on your phone? My guess is that you punch in the numbers as if
the hyphens weren't there.

... The rest of this number/string variable naming crap is just personal preference.

Just to be anal, I think programmers tend to use "int" or whatever
numeric type a bit too quick. As soon as something is a "number" it is
immediately smacked into an int. I think the golden rule should be:



"Is it a number? If your'e not doing calculations with it, it's probably a string"



I've seen systems where bank account numbers are stored as "NUMBER" in
an oracle database. Now, whe storing and retreiving data, it becomes
really hard to see the difference between "1234567" and "01234567"
(which are clearly different bank account numbers, at least where I
live)



And I haven't even begun to tell about people using "Float" to store
these numbers and have to round() when converting between persistant
and in-memory types. ugh.