- 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
We Germans have the wonderful word "Zitronenfalter". It can either be interpreted as a brimstone butterfly, or as a person who folds lemons for a living.
Admin
The point is that you can call someone without knowing or caring about any dashes. The dashes don't add any information since phone numbers follow a prefix code. E.g., when I dial "089xyz" on a phone in Germany, the call will be directed to a recipient in Munich, no matter what "xyz" stands for (ok, if it's anything valid, that is). There are no city codes that start with another city code (like "8976" that would start with the "89" for Munich), hence there are no ambiguities and I can infer the meaning and location of any "sub-numbers" just by looking at the digits alone. The dashes just make it easier for someone who doesn't know all the city codes and such.
Admin
Where do you live, Rolf? In Germany, "01234567" is taken to be the same account number as "1234567", while "12345670" can (but needn't be) a different or an invalid account number. Reminds me of the "Hartz 4" software debacle ...
Admin
I would hate to know what will happen if 2 new statuses gets added later. Do you have to go and rename all your variables!?
Admin
Ever tried an IDE with code-insight (or equal) functionality. With insight this might be actually even useful practice, especially if the platform doesn't have enumerators and no javadoc-like functionality either.
Nothing to do with point and click
Admin
Hints of a bad software design/analysis practices :P
And it's really not that hard use automated search and replace over the project ..
Admin
Re-read what I wrote. Each number group in a US/Canadian telephone number has a distinct meaning. To dial a hypothetical number 987-654-3210, I can dial the sequences 3210, 43210, 6543210, 16543210, 06543210, 9876543210, 19876543210 or 09876543210, depending on my location, the location of the number to be called, and the billing options. Oh, and there's the whole leading-zero thing to deal with. It ain't a number, and should not be treated as such.
Admin
Just imagine the problems if we programmed zip codes as ints instead of strings.
Address joe = new Address(); joe.zipCode = 06341;
cout << joe.zipCode << endl; // Prints 3297.
The USPS scanners go WTF? and reject the mail.
Admin
Oh god no, that just compounds the problem. Some call fails and passes a null pointer back and you want to accept that as valid? All that does is propogate bad data.
Enum types need a isValid() function to test for someone harassing your function, so you could quickly find out if you got passed a bs number so you don't have to test everything in every function (or screw something up).
Admin
The "Java version" of an enum has never been like this. Unfortunately, it has just been erroneously implemented like this such that this kind of atrocity has saturated to the point of being an accepted norm. Type-safe enumerations have existed since Java 1.0, only nobody has really had any clue about how to implement them appropriately. Unfortunately, I still see it occur, albeit being a point made on various marketing brochures these days. Ignorance is bliss.
Admin
"Brimstone butterfly?" Is that a fancy way of saying "fart?"
On a side note, I agree with Manni. Yes a programmer needs to communicate with users, but his code doesn't need to be read by them. And if your users can't learn to click on "Project Code" instead of "Project Number" then maybe terminology is not your problem.
Admin
Applications, in general (that exludes SAP), do not create business processes -- they mirror and automate them. The terms "Project Number" and "Project Code" usually predate the application (and, as I said before, may both exist in the same process, but with completely different meanings). Code does not live in isolation -- it is every bit as important to be able to quickly answer the question "where the f*** does this come from" as it is to answer "what data type is this?". Any code that needlessly obfuscates the business sense of a value is as bad as code that needlessly obfuscates the type. I'm not a big fan of Hungarian notation, but there is room for both a meaningful name (in the business sense) and a type indication in a variable name.
Admin
The Number/String thing getting people so worked up is kind of scary. If the client application shows the user a field for "Product Number" and phone operators ask callers for their project number to assist them and all the business logic has been produced in meetings with the business owners that since the company's inception use the term "Project Number" to describe a string of characters used to provide a unqiue sequential identifier to index individual projects....then please for the love of god call it a Project Number in your code.
If I can across a line of code like:
String ProjectCode; //called Project Number in UI because people are too dumb to understand data-types
...I'd submit it to the daily wtf.
If you are paid to build software, do that, don't wage passive-aggressive personal battle against the data-type ignorants of the world via the naming conventions of your variables. If its not something you do math on, put it in a string. And if it is used to provide sequential unique identifiers and everyone else calls it a something-number please call it by the name everyone else can identify it by... don't be a hero.
Admin
As others have pointed out, "number" doesn't necessarily mean "integer" or even "string of digits." What hasn't been mentioned is one 100% unambiguous example of this: in the U.S., a license plate number almost always consists of a mixture of letters and digits.
Admin
Actually in the Netherlands the literal translation of License plate is 'Number plate', all current plates have at least 2 letters in them 00-XX-00, 00-XX-XX. No vanity plates here so you can be sure there are no number-only numberplates [:P]
Drak
Admin
Maybe they like to store all their 'numbers' in base 36?
Admin
Technically it's not necessesary, thought it would defeat the purpose of this naming not to do so.
Depending on the used tools, renaming can mean some work or next to nothing. For example, when you write java code in Eclipse, renaming a field or method of a class (throughout the whole program, of course) is easy, since Eclipse provides a tool for that job.
Admin
Oh, that's just like this entry I submitted myself - http://www.thedailywtf.com/forums/24005/ShowPost.aspx , the wonderful
Admin
On the whole number thing...
Like in the Netherlands, we call our "license plate" a "number plate" (I think this is in some ways better because a license is quite different). However, a "number plate" can be something like L429 RAB (each character has some sort of meaning - the L in this case denotes the age of the car).
In terms of phone numbers, again, the leading 0 is important since in the UK 113 123456 is an invalid phone number - the 0 is important since it tells the exchange that you're dialling another area code (so you'd have 0113 123456). If you put your phone number into a numeric field, you will lose data.
Now, however your app uses this data, losing the leading 0 is catastrophic for a phone number. If it's an automated dialler (such as a dial-up connection or mobile phone) then it'll be constantly dialling wrong numbers. If it's going to display it to the customer, then dropping a 0 will confuse them.
Of course, it all gets even more fun when you have international phone numbers (because the usual notation for this is to prefix a + sign: +44 113 123456)
And you can't just call it "phone code" or whatever, because (besides the point that's already been raised about the connection between programmer and customer) any new programmers will come along, and say "WTF is a phone code?"
Admin
WTF, the failing call should have thrown an exception! Why allow the "bad data" to propagate in the first place?
Otherwise you get V's like this:
String s1 = f1();
if (s1!=null)
{
String s2 = f2();
if (s2!=null)
{
String s3 = f3();
if (s3!=null)
{
// Use the three strings...
return f4(s1,s2,s3);
}
else
{
// report error
}
}
else
{
// report error
}
}
else
{
// report error
}
Wouldn't you rather debug this:
try
{
String s1 = f1();
String s2 = f2();
String s3 = f3();
return f4(S1,s2,s3);
}
catch(FunctionException e)
{
// report error
}
Admin
Yes, your phone company allows you to dial shortcut versions of the phone number. If you leave the city code away, you end up calling someone in the same city region, etc. What exactly are you trying to tell me, though? As I stated before, the non-numeric parts of a phone number contain zero bits of information, they are entirely redundant. Which means that they are exactly the optional mnemonic aids that you said they weren't. Or do you mean the phone number is not a number because it can be divided into "number groups with distinct meaning"? Well, I can divide any integer into number groups with distinct meaning, e.g. using the Chinese Remainder Theorem. Does that mean they aren't numbers?
Admin
Google is your friend.
http://images.google.com/images?q=brimstone%20butterfly
Admin
I'd never thought this would be the place where someone would imply that users are smarter than programmers. You expect your user base to recognize what everyone calls "Report Number" is called "Report Code" in the UI, but, good lord, if you call a character string a Report_Number then the programmer's little brain will just explode. Must be due to using that dang Hungarian notation too much.
--RA, writing just down the hall from office number 6-54A
Admin
Alexis de Torquemada wrote:
Exactly. I'll also add that phone numbers break in different places in different countries. Where in the UK you might use xxxx xxx xxxx formatting, in France it would be xx xx xx xx xx
The actual content of phone numbers is carefully regulated, so that your call to a mobile won't translate into a call to nigeria. Which is to say: The spaces and dashes that you might put into a phone number are completely unnecessary padding and contain zero information, no semantic meaning and are utterly redundant, as Alexis says. The information is contained in the number itself.
And it should be stored as a string.
Simon.
Admin
The fact that the number groups in a telephone number have distinct meanings has nothing to do with whether the whole sequence is a number or not. In fact, if you look up the definition of the word "number", you will see that it is not strictly defined as an "integer". It is also defined as a "series of numerals... [e.g.] telephone number." (Yes, look it up - try the American Heritage Dictionary.)
Take particular note than in your average integer, which is also usually represented in (decimal) print as a sequence of numerals, each individual digit has a distinct meaning based on its placement within the sequence. (Not all number systems have this property.) Said property does not disqualify either run-of-the-mill integers or telephone numbers as being "numbers".
The significance of leading zeroes is also irrelevant; all that means is that if you convert it to an int in a programming language, you may encounter lossage. But that still doesn't mean it's not a number.
(How you treat particular types of numbers in code depends quite a lot on what characteristics of the number in question you wish to preserve. Sometimes a string representation of a numeric sequence of digits makes a lot more sense than a binary integer, but both are undeniably numbers.)
Admin
You are almost right.
The Microsoft operating system people started using Hungarian notation after seeing the Office people use it. However they did not understand it. They usually used it to indicate basic type information. This is more useless then tits on a bull. Of course lots of people saw this and emulated it. This poor imitation of Hungarian notation deserves all the bile that we spew on it.
The Hungarian notation used by the Office people and by Apple was designed to systematically enrich the readability of the code by indicating the function of the variable, not its type. For instance, one might have three integers. The first might be a resource handle, the second might be a flag, and the third might be a size. Each of these functions would have their own prefix and thus, despite the fact that they are all integers, a programmer familiar with the naming schema would be able to distinguish them at a glance.
Keep in mind that this is late 80s/early 90s when lots of application code is still being done in C. C won't at compile time catch that a programmer passed an integer containing flag values where he should have passed an integer containing a resource handle. Also remember that many compilers of the time had much tighter limits on how long varaibles could be. Today, instead of holding a resource handle in an integer, we'd probably wrap it in an object. Now the compiler will catch these issues for us.
Admin
We use a similar notion for the columns in our databases, and I think it makes sense.
For example, instead of "ORDER_NUMBER", we write "NUM_ORDER" (but that doesn't mean that the column type is NUMBER, can be VARCHAR as well).
Admin
There are people who fold lemons for a living?
Admin
<FONT face="Courier New" size=2>i'm remembering the scene in "this is spinal tap" where nigel has some trouble with the meat/cheese/crackers.</FONT>
Admin
I had a problem once where an XML schema defined a DUNS number as an integer. The software that rendered the XML would normalize the value in the output. This meant that any leading zeros on the DUNS number would be stripped off. All DUNS numbers must be exactly 9 digits. The receiver of these documents would reject them as invalid. The solution? Change the schema to specify that the DUNS is a String matching regex: "\d{9}" Just because a String contains all digits doesn't mean it's to be treated as a number.
Admin
It's so hard to find good lemon folders these days.
Admin
Admin
ObjectPascal/Delphi also does enumerations nicely, the only thing missing is automatic conversion to strings:
type
TGoodFood = (gfSpam, gfEggs);
const
strGoodFood: array[TGoodFood] of String
= ( 'Spam', 'Eggs' );
I don't remember if you can do this typecast:
TGoodFood(42);
Admin
I mean it is not a numerical-type value, and should not be treated as an integer (or a long or, god help us all, a floating-point type). It is a hierarchical identifier whose component parts all happen to be represented by groups of digits. And yes, the break points matter, since they indicate dialing rules which are not the same across systems. Of course, if you are designing a system that doesn't actually do anything with the phone numbers, that wouldn't matter a whit. If, on the other hand, the system even presents the number to a user so that the user can dial a phone manually, then the breakpoints actually matter.
Admin
OneFactor said:
ML:
datatype alignment = alignLeft | alignRight | alignCentre;val foo:alignment = 1;
causes
Error: expression doesn't match constraint [literal]expression: int
constraint: alignment
at compile-time. Associating enum vals with numbers is fiddley, tho.
Admin
<FONT face="Courier New" size=2>i miss ML. *sniff*</FONT>
Admin
emptyset said:
Yeah, polymorphic typing is bloody brilliant.
By the by, now I think about it, converting ML enums to numbers is actually pretty easy:
datatype alignment = alignLeft | alignRight | alignCentre;val align2int = fn alignLeft => 0 | alignRight => 1 | alignCentre => 2;
This means listing all the possibilities for the enum twice, but if you forget to update one when you change the other, you'll either get "
Error: match redundant" or "Warning: match nonexhaustive" at compile-time, so it's still safe.Admin
Jobs are scarce in modern-day Germany. You can't afford to be picky.
Admin
Ok, though there are lots of numbers that I wouldn't store in an integer variable, anyway.
Sigh - no, they don't. It doesn't matter one bit (no pun intended) that dialing rules aren't uniform. All that matters is that every phone number can be unambiguously expressed by a prefix code, or let's say a hierarchy of prefix codes. See http://en.wikipedia.org/wiki/Prefix_code
Example: +491805016565. I included the plus symbol for clarity, but assuming that you simply store every phone number in this "fully qualified" (e.g. location-independent) format, it's completely redundant.
Since country codes are organized in a prefix code, there is only one match: 49 for Germany. Then comes "1805", which denotes a special German city code for "service numbers". And finally 016565 denotes the service number that you'd be connected to when dialing this number, in this case the extremely popular (wink) organization that collects the fees for German public TV and radio stations. Country codes follow a prefix code, German city codes follow a prefix code, etc. There is no ambiguity, even without separators. If there was, you'd either need "dash" keys to dial a number, or timing would matter.
Admin
Pretty much. You wouldn't believe how much googling I had to do to find the right combination of words to find someone talking about the evilness of comments in code.. [:)]
Admin
So what happens when the user types his number without the country code:
0113 123 456
as I normally do? (this user being in the UK)
Admin
I'm not sure why we're having this big argument over the storage of certain "numbers" as strings. Say what you want about the hyphens in SSNs and Phone numbers, but they are only there to make them more readable to humans. They do not matter in the big picture of data type usage for these values.
The main thing everyone should keep in mind as the main reason to store these numbers as strings is the leading zeroes. That's the sole deciding factor in what data type should be used.
Admin
I disagree. In order to make your data human-readable, you now have to convert it from pure numeric to numeric with dashes, or whatever, which is in most cases unnecessary. You just make more work for yourself. The exception is when you need to do something with the data (like adding it to another value) and therefore need it as a number.
Of course, the other side of the coin is when you need to parse the value and do something with it. Possibly, the only way for a program to recognise a specific part of the value is based on these 'aids'.
I'm not sure why this big argument has started either, though.
Admin
I'm not sure exactly what you are saying. If you store the SSN of someone as a string, you can either store the hyphens, or specify a format string when outputting it to the user. The main thing is that if you have leading zeroes and you store it as an integer, then you have problems with leading zeroes.
Someone mentioned earlier in this thread a good general rule: If you are not performing any mathematical operations on the "number", then you should probably store it as a string. There is no case where you would be performing math on SSNs and phone numbers(except perhaps comparison).
Admin
Yeah, using a string definitely helps with the leading zeroes. Unfortunately, if you use a string datatype for the number "just to be safe", and the business decides against leading zeroes, then you have a problem when asked to order by that field - 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9. I know there are workarounds but it is easy to forget to implement the workaround. All in all, it is the lesser of two evils though.[H]
Admin
"If you are not performing any mathematical operations on the "number", then you should probably store it as a string."
Oh. I thought you were saying "if it doesn't have leading zeroes, store it as an integer." My point was that there are other reasons for storing the data as a string than just the leading zero.
And yes, this is a good general rule.
Admin
>Speaking of which, do any languages do Enum's properly?
I am tempted to reply Pascal and its derivatives, and maybe Eiffel.
Admin
Pascal used to enforce this with runtime checking to ensure that value were in range. The difference between strongly and weakly typed languages. I'm pretty sure Ada is probably equally as stringent about this.
Admin
If the call fails, it should throw an exception. A null return value can and should have a well-defined meaning. In the case of an enum, it might be displayed on the GUI as a dropdown selection box, then a null value could indicate that the user has not yet made a selection. Still, it would be a much better solution to have that as one of the enum values rather than a case that must be tested for specially.
That's ridiculous. Clearly the Right Thing(tm) is for enum types to ALWAYS contain a valid value so they CANNOT be screwed up (at least not that way). It's perfectly possible to implement them that way; unfortunately this is rarely done.
Admin
Hey, don't you mean
public static int isTrueReturnsTrueIfTheArgumentIsTrueAndFalseIfItIsNotTrueAndARandomResultIfItIsNeitherTrueNorFalseToAvoidBias( boolean t){
??