• (cs)

    As long as state abreviations are unique they would be excellent candidates for a primary key. I don't see the point to add an extra column just for that. I use it for country abreviations too.

    Hardcoding states or countries is never a good idea tho! :) I hope that the US don't add or lose any states in the future.

    The code looks like perl, but in that case @data[0] should be $data[0]... !?

    Wow... my first FIST ever! :D

  • niggles2 (unregistered)

    What. The. Fuck.

  • Merlinou (unregistered)

    I think that this is designed to display a customized list of states. If you're contacting about a product available only in Texas and Utah, only those will be shown. So there is a flag for each state to indicate whether it should be shown or not.

    I agree that this is strange way of doing it but at least it's readable. And having readable Perl code is already a good start.

    (I remember a job where one of the first sentences of the Perl developer I was replacing was "I put all the code of the application in a single file because I didn't know how to use modules." Of course, it was printing html all over the code...

  • (cs)

    It's pulling Database-like data from a file instead of a database! SMART! After all, who would want a database when you can have a nice portable file, am I right, am I left?

  • Greg (unregistered)

    Cmon, he's using flags. Programmers love those, right? And its (sortof) binary data so it must be really efficient, right? :/

  • hakon (unregistered) in reply to Coditor
    Coditor:
    As long as state abreviations are unique they would be excellent candidates for a primary key. I don't see the point to add an extra column just for that. I use it for country abreviations too.

    "As long as ..." is the key. Since customers are intrinsically evil, and business logic is naturally in flux, state abreviations WILL change to make them non-unique, and it WILL be popular to use AA instead of AL for Alabama at some point in the future.

    The trick it to not think about your data at all, when you decide on your primary key. The PK is not your data, and your data is not your PK.

  • Frazer (unregistered) in reply to Coditor

    The real WTF is that @data[0] works in Perl. I learned something today.

    perl -e '@x=qw(foo bar); print @x[0]'

  • Erik N (unregistered) in reply to Coditor

    Yeah it's Perl and the @ probably should be a $ since he's trying pull a scalar, but Perl is flexible and it probably works. Lousy way to code.

    Using the postal abbreviation is fine if your app is always and only going to deal with US states/territories. If your app is international, using the international country codes (US, DE, GB, etc) are fine since those are going to be unique. However you may not want a table for each countries states/provinces/terrirtories/regions/etc so a general purpose table would want a numeric identifier for each row since you never know if China may have a OH region.

    If you use an Integer it is most likely to only be an extra 4 bytes per row. Remember how much trouble we had with mainframes and Y2K because somebody wanted to save 2 bytes? (ok storage cost alot more back then than it does now).

    I'd never advocate going hogwild in future proofing your app, but if it's simple and easy to implement you might as well do it.

  • DJ Beret (unregistered)

    He probably doesn't use warnings; in his Perl code. Otherwise he would get:

    Scalar value @data[0] better written as $data[0] at filename line 5.

  • Fernando (unregistered)

    It's really weird the way some guys spend their time.

    Two points to consider:

    1 - What's the problem about using an auto generated PK? We're talking about 50 states only. It is because of space??? Art?? Religion? Philosophy?...

    2 - Why is so hard to do things the way normal people do instead of proving your intelectual superiority at each line of code you write?

    Really weird...

  • Laie Techie (unregistered)

    @data[1] returns an array with a single item (the value of $data[1]). We all know that in scalar context, arrays have the value of their length.

  • 2bithacker (unregistered)

    The @array[0] syntax is valid because it's how you get array slices in Perl. Technically it's returning a list of 1 value from the given array, rather than returning one scalar value with the $array[0] syntax. It's perfectly valid, but could lead to unexpected results.

    @array = (5);

    $array[0] == 5; # true $array[0] == 1; # false @array[0] == 5; # false @array[0] == 1; # true

  • whatever (unregistered)

    State abbrs can be fine for primary keys, but if they ever change (I know I know, but Canada did this with the abbrs of their provinces) you'd have a mess.

  • (cs)

    Ugh. I don't get these people. If I have to type out a list of the states (let alone the surrounding code) even once, I would stop at about Arkansas and say, "There has got to be a better way."

  • Some DBA (unregistered) in reply to hakon
    hakon:
    Coditor:
    As long as state abreviations are unique they would be excellent candidates for a primary key. I don't see the point to add an extra column just for that. I use it for country abreviations too.

    "As long as ..." is the key. Since customers are intrinsically evil, and business logic is naturally in flux, state abbreviations WILL change to make them non-unique, and it WILL be popular to use AA instead of AL for Alabama at some point in the future.

    The trick it to not think about your data at all, when you decide on your primary key. The PK is not your data, and your data is not your PK.

    Nicely stated. Another good reason to use an integer PK is efficiency with portability. A very intelligent database can build a good index on a two-letter abbreviations. Even a dumb database can build a great index on integers. And you never know when you'll need to change your database vendor.

  • Dave (unregistered)

    Wow...

    That's it. Just Wow.........

  • (cs) in reply to Erik N
    Erik N:
    Using the postal abbreviation is fine if your app is always and only going to deal with US states/territories. If your app is international, using the international country codes (US, DE, GB, etc) are fine since those are going to be unique. However you may not want a table for each countries states/provinces/terrirtories/regions/etc so a general purpose table would want a numeric identifier for each row since you never know if China may have a OH region.

    Actually, you do not even have to look as far as China. If you mix US states and country codes, you end up with Canada and California both having CA as an abbreviation.

  • derverdenhermen (unregistered) in reply to Anonymous Coward

    So use country code and state code? USCA and CACA.

  • David Schwartz (unregistered)

    Odds are he wrote a program to generate the code, rather than typing in all fifty state names several times. There are times when using a program to generate a program makes sense, but it should always set off alarm bells in your head. You should at least consider modifying the program that makes the program into being the program as that often makes a lot more sense.

    This is definitely one of those cases.

    We're pretty unlikely to need to add more states, but look at the complexity of auditing that code. What if one state got left out of one of the places all the states are listed? Would you catch it? What if one of the state flags was mis-abbreviated in one place? Would you catch it?

  • Binarycow (unregistered)

    The real WTF is not including APO states for us military folk.

    APO (City) States: AE (Armed Forces Europe) AP (Armed Forces Pacific) AA (Armed Forces Americas)

    So annoying to find the right product... but the merchant doesnt ship to deployed military.

  • (cs) in reply to 2bithacker
    2bithacker:
    The @array[0] syntax is valid because it's how you get array slices in Perl. Technically it's returning a list of 1 value from the given array, rather than returning one scalar value with the $array[0] syntax. It's perfectly valid, but could lead to unexpected results.

    But that would probably mean... all of them are always... oh God... oh GOD!

  • (cs)

    I only see one state: confusion.

  • Shit (unregistered) in reply to derverdenhermen
    derverdenhermen:
    So use country code and state code? USCA and CACA.
    Did you know that CACA means shit?
  • hakon (unregistered) in reply to derverdenhermen
    derverdenhermen:
    So use country code and state code? USCA and CACA.

    God, no! You've begun thinking creatively about your primary key!

    I'm not even being sarcastic when I say that you should never have to think about your PK. Remember why you have a PK: It's to index data and to uniquely identify a row in a table. Why would you want to be able to perform concatenations on it? Do you have to split up your PK and have the shattered parts contain semantics? It's the dawn of dev hell.

  • Mr. Nobody (unregistered) in reply to Laie Techie

    The fun thing is that, based on the rest of that code, the file its reading things from looks something like:

    Contact Us Form|||||||||||||||||||||||||||||||||||||||||||||FILE_NOT_FOUND|||||||||||||

    Okay, so I lied. I didn't count all the |s and FILE_NOT_FOUND could be anything and only its POSITION in that data marks which state you are. I love how they put the string "Contact Us Form" into two different variables, too.

    That said, except for this part, at least the Perl is reasonably readable, especially for a WTF.

  • Matt (unregistered) in reply to 2bithacker

    Actually, in Perl a list is different than an array and hence your logic is not valid. A list will return the last value of the list in scalar context. (An array, however, will indeed return the size of the array, as you stated) An array slice evaluates to a list, not an array. Hence, the table you posted is in actuality:

    @array = (5);

    $array[0] == 5; # true $array[0] == 1; # false @array[0] == 5; # true @array[0] == 1; # false

    As it should be.. however, using the array slice notation confers a 'list context' on both the array subscript and on any expression being assigned to the slice which could cause unexpected results. (Not to mention the fact that using an array slice in the place of a scalar array access doesn't have the visual cue that you're working with a single value and hence leads to confusion, such as you have experienced above) :)

    Matt

  • Matt (unregistered) in reply to Matt

    I guess I should also add... TRWTFs are:

    • No use of 'use warnings;' and 'use strict;' pragmas
    • No use of non-interpolating single quotes (or quote-like operators) to avoid backwhacking double quotes.
    • Using 'eq' instead of '==' to compare what is obviously a numeric value
    • capitalized variable names
    • Using an iterator variable to iterate over the contents of an array rather than: for my $line (@FILE) { ... }

    (And of course, the WTF-ed-ness of the entire algorithm to begin with, and the aforementioned use of slice notation)

  • Smash (unregistered)

    This reminds me of a code snippet I came across on my last job. I had to maintain a somewhat large Delphi-written ERP. The real WTF was that, even though it was internal development, nobody could tell me exactly what were the requirements for that part of the system. To top it off, its original coder was long gone.

    Most of those units were ok, but one day my eyes fell upon something like this:

    { starts by loading boolean values of four checkboxes into a four-positions array of highly suggestive name like arr[] }
{ then it comes the IF reproduced below }

if (arr[0] = true) and (arr[1] = true) and (arr[2] = true) and (arr[3] = true) then
  flag := true
else
  if (arr[0] = true) and (arr[1] = true) and (arr[2] = true) and (arr[3] = false) then
    flag := false
  else
    if (arr[0] = true) and (arr[1] = true) and (arr[2] = false) and (arr[3] = false) then
      flag := false
      
  { it goes on and on, for all 16 possibilities }
  if (arr[0] = false) and (arr[1] = false) and (arr[2] = false) and (arr[3] = false) then
  flag := true;
  
  if flag then
  begin
    { some code }
  end
  else
  begin
    { some other code }
  end;

    Not believing my eyes, I checked with my supervisor and he suggested I should leave it like that, but it was up to me to decide. I did some research, talked to users and checked the code, and it became clear that the users could choose any checkboxes except all of them at once or neither at all. A Karnaugh map analysis confirmed it (not entirely, though. One condition appeared twice whilst another wasn't verified)

    A few minutes later, the following IF replaced the former:

      if ((arr[0] = arr[1]) and 
      (arr[1] = arr[2]) and 
      (arr[2] = arr[3]) then
  begin
    { some code }
  end
  else
  begin
    { some other code }
  end;

    Too bad I didn't know this site back then. It would be a nice CodeSOD

  • Resa (unregistered)

    Ahhhh...my eyes...they burn...ahhhh

  • Richb (unregistered) in reply to hakon

    The real trick is to use the iso standards (3166 and 3166,2 iirc)... then its even compatible with other implementations of the iso standard... horrifying eh?

    captcha - I like as a dba = inhibeo ;)

  • 3.14159265358 (unregistered)

    Use an array of strings, e.g. state = ("Alabama", ... , "Wyoming");

    But it's nice to use useless loop unrolling.

  • oopsiedaisie . (unregistered) in reply to Smash

    errr.. is it just me or does it appear that there's a bracket missing?

    ORIGINAL: if ((arr[0] = arr[1]) and (arr[1] = arr[2]) and (arr[2] = arr[3]) then begin

    CORRECTED?? if ((arr[0] = arr[1]) and (arr[1] = arr[2]) and (arr[2] = arr[3])) then begin

    idk to be honest .. bt yeah .. =]

  • (cs) in reply to Some DBA
    Some DBA:
    hakon:
    "As long as ..." is the key. Since customers are intrinsically evil, and business logic is naturally in flux, state abbreviations WILL change to make them non-unique, and it WILL be popular to use AA instead of AL for Alabama at some point in the future.

    The trick it to not think about your data at all, when you decide on your primary key. The PK is not your data, and your data is not your PK.

    Nicely stated. Another good reason to use an integer PK is efficiency with portability. A very intelligent database can build a good index on a two-letter abbreviations. Even a dumb database can build a great index on integers. And you never know when you'll need to change your database vendor.

    Also, in Oracle's Apex, generated reports and forms don't let the user edit the primary key. So things work a lot smoother if you have an integer PK.

Leave a comment on “Classic WTF: Now That is a Way to do States”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article