- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Bagsy first post!
Brillant, a way of embedding comments in variable names...
public static int isTrueReturnsTrueIfTheArgumentIsTrueAndFalseIfItIsNotTrue( boolean t){
anyone?
}
J
Admin
Did the language not have constants, either?
Admin
Admin
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.
Admin
Consider yourself fired.
Admin
WTF -- Will the real JohnO please stand up?
Admin
Very clever. Helluva lot better than something like "st as int".
Admin
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.
Admin
*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.
Admin
Yes, but what if their report "number" was : "E790-A" and their project number was "7M3-TMJ" ?
Admin
<FONT face="Courier New" size=2>like FOCUS (tm)?</FONT>
Admin
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.
Admin
Didn't that language even have comments so they could have just written a comment what different values mean?
Admin
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'?
Admin
No! Because comments are evil!
Admin
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.
Admin
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.
Admin
And if they allowed eight characters, then they could have "numbers" like "528-9983".
What is *your* phone string?
Sincerely,
Gene Wirchenko
Admin
Funny enough, your Social Security Number is not a number either, and neither is my Social Insurance Number.
Have an unnecessarily literal day, folks
Admin
Maybe this is to make C# more C++ like?
From "The C++ Programming Language Third Edition":
Admin
While this is dumb I don't think it really is up to the level of a wtf
captcha: business
Admin
That's the biggest kind of crap I've heard, no, read, in a while to be honest.
Admin
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....
Admin
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?
Admin
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.
Admin
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?
Admin
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...
Admin
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.
Admin
I'll bet you had to walk to school. Uphill. Both ways.
Admin
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...
Admin
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.
Admin
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.
Admin
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.
Admin
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
Admin
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.)
Admin
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.
Admin
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.
Admin
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.
Admin
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. ;)
Admin
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
Admin
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.
If we always stayed 100% on-topic at all times on all discussion boards, there would be very few interesting discussions.
Admin
There aren't a lot of joker-proof languages, but I think Haskell matches your criterium.
Admin
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.
Admin
Oh my god, it's Bob!
Greeeeat singer, Michael Bolton. eh-eh-eh, yeah, really like him, too.
:-)
Admin
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.
Admin
These are irritating conventions, but shouldn't a programmer know better than this?
Admin
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.
Admin
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.
Admin
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.
Admin
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.