Comment On Party Like It's 1969

oh god kill me now!

I am sure there's a very good excuse for this.



Nobody would store all the data to a class in a single string without
good reason. If they don't have a good reason, they should be dragged
out back and shot.

The real WTF here is the
number of hoops you have to jump through to make Java properly align
strings on machine word boundries for good performance!

How much do you want to bet that he didn't even define toString() to return that string either?

head.  hurt.  must.  kill.

proof possitive that you can't teach an old dog new tricks, but you can teach him to bark in a different language...

If the class is a wrapper for processing records stored in a flat file then this code makes sense.

It would make more sense if data was initialized:



String data = new String( new byte[80] );

Maybe this was developed using

http://www.legacyj.com/legacy2.html

 

[:O]

Believe it or not, people *still* do new development this way.  Needless to say, there is almost always huge conflict between the old and the new on issues like this.

Last year, I worked on a project that had 3 distinct values stored inside of a single database column.  Every time that column was pulled out, it had to be parsed into its 3 seperate values.  Worse yet, the fields weren't fixed width.  Rather than store the values as 3 seperate database fields.  Needless to say, I took great exception at this. 

Also found in this system were dates and numbers stored as strings rather their appropriate data types.  Very, very, very poor and non-negotiable design. 

To this day, I still have nightmares about that system.

That code is awesome.  It totally looks like somebody machine-translated from cobol to java and then massaged the output a little.

I have am dealing day to day with someone who decided to have a DB
field with comma separated strings in it. Such as: lastname, firstname,
other table's primary_key. It makes joining tables very fun. Luckily, I
have found my savior for this: mysql's SUBSTRING_INDEX! Ugh, it's a
nightmare.

Anonymous:

I have am dealing day to day with someone who decided to have a DB field with comma separated strings in it. Such as: lastname, firstname, other table's primary_key. It makes joining tables very fun. Luckily, I have found my savior for this: mysql's SUBSTRING_INDEX! Ugh, it's a nightmare.

In MS SQL Server, you can have a "Computed column": a column which is not actually stored in the DB, but calculated on the fly when refered.  If mysql has such a feature, create new columns in the table (as should have been done in the first place), run a process once to split that field into the proper columns, then create a computed column as "FirstName + ',' + LastName + ',' + OtherColumn"

Then, you can use the column as the Good Lord intended, and any legacy code can read the comma separated field as it expects.  The only things that must be changed are places the try to write to the CS field, but the separate fields should make that code simplier..

 

I have to admit: I'm just about to
rebuild an SQL database to use string dates.  It's a database of
awards given by past and present royalty in my kingdom in the Society
for Creative Anachronism.  A particular person might know, for
example, that Prince Alfar gave them an Award of Arms in 1996, but they
don't recall the month, or perhaps it was an Order of the Rose Leaf
from Prince Brusi in May of 1992, but the day is unknown.  Rather
than kick these people out of the database completely (and have them
constantly email me to complain), I figured I'd store dates as
yyyy-mm-dd, where the dd and mm could be replaced by ?? if
necessary.  It's slightly more work to process, but it's
acceptable, and as a kludgy side-effect, it means that 2005-03-?? sorts
after 2005-03-31, meaning that complete dates have precedence over
partial ones.



So: string dates -- not always a bad idea.

my jaw is still on the floor somewhere.



bloody hell.

Mike R:

I am sure there's a very good excuse for this.

There always is. "The dog ate my homework too"

I deal everyday with a product that keeps a comma separated list of guids in one field, it even puts the number of items at the front like so "3;one,two,three".

Fun fun fun, this is a major product from a mjor company, the profile's addresses in  Microsoft Commerce Server.

 

 

JamesCurran:

In MS SQL Server, you can have a "Computed column": a column which is not actually stored in the DB, but calculated on the fly when refered.  If mysql has such a feature, create new columns in the table (as should have been done in the first place), run a process once to split that field into the proper columns, then create a computed column as "FirstName + ',' + LastName + ',' + OtherColumn"

Then, you can use the column as the Good Lord intended, and any legacy code can read the comma separated field as it expects.  The only things that must be changed are places the try to write to the CS field, but the separate fields should make that code simplier..

 

(If using SQL Server 2K) you can create a view with the computed column and use INSTEAD OF UPDATE and INSTEAD OF INSERT triggers on the view to handle writes from the legacy code base.

 

Long live woodstock! Let's go streaking y'all! [:p]



==================



I'm having a hard time trying to teach an officemate VB.NET after years
of being stuck in COBOL, but there is hope for her. At least she can
use Collections properly nowadays, after around 6 months of making
COBOL "go away".

Some positive note:

1. The code is created with serialization in mind. It would be a breeze to implement serialization to the object.

2. It leverage the advantage of OOP. You don't care how an object
implemented, you just glad it is encapsulated well within the
particular class.

bat:

I figured I'd store dates as yyyy-mm-dd, where the dd and mm could be replaced by ?? if necessary.  It's slightly more work to process, but it's acceptable, and as a kludgy side-effect, it means that 2005-03-?? sorts after 2005-03-31, meaning that complete dates have precedence over partial ones.

So: string dates -- not always a bad idea.

Drop the '-'s and we can talk [:D]

Drak

Ya-huh.  I put 'em in cos
there are way too many people who think the only real date format is
month-day-year, and they were going to complain that 20050331 means the
5th day of the 20th month in the year 0331, and why on earth didn't I
know that the Gregorian calendar wasn't in use in 331AD?



Practically speaking, tho, I'd
rather store dates with the dashes: in the unlikely event that I might
one day have to hand-edit an SQL dump to fix some insanely WTF-worthy
bug, I'd like to be able to see what I'm doing.  Two bytes per
user is nothing compared to even such a minute improvement in debugging.

Could you not have used separate columns for day, month and year? Then you would be able to use proper NULL values for unknown months and days. And the order would not be ambiguous.

Why didn't you store them in three columns to begin with?



Year, Month and Day ? Then you could have null values in whichever field is unknown.



And no parsing of strings, and easy to join...

Drak:

bat:

I
figured I'd store dates as yyyy-mm-dd, where the dd and mm could be
replaced by ?? if necessary.  It's slightly more work to process,
but it's acceptable, and as a kludgy side-effect, it means that
2005-03-?? sorts after 2005-03-31, meaning that complete dates have
precedence over partial ones.

So: string dates -- not always a bad idea.

Drop the '-'s and we can talk [:D]

Drak

Use integers instead of strings, it's even more fun.

Maybe the programmer wanted to save memory. Putting everything into a
single string requires less memory than having a string object for
every field. ;-)

As a side effect, you can "group" fields like cobol does with the
"redefines" clause: For example, if data.substring(0,9) represent field
x and data.substring(10,19) represent field y, than

data.substring(0,19) represent a composite of x and y.

Since Cobol can do things like that, any translation of cobol programs have to find a

way to do the same, especially it the translation is done by a program.

How about this as an alternative for dealing with imprecise dates?




Instead of storing an incomplete string date, where getting the
sematics right could be rather tricky, why not store two dates: an
earliest possible and latest possible date?  If the date is known
precisely, these would be the same of course.  That way, you allow
people to be precise as they can be.



For example, if they know they were given the award on a particular
weekend, but they are not sure what day, they can be precisely
imprecise ;-) and enter Friday as the earliest possible date and Sunday
as the latestet possible date. By using strings, you force people into
quantum date ranges, which may not accurately reflect their knowledge
of the event.

Hell, SQL's real support of date data is so poor, you might as well store them as integers or strings. ANYTHING that might possibly be groupable, because having to winnow throught the various vendor variations just to get data grouped by day of the week or by date is pretty much impossible to do without throwing away sql's main benefits and binding to a vendor.

And if I gotta live with a few -'s, fine, as long as they are ALWAYS there.  Nothing worse than data that requires a fixed format but relies on humans to do it

An interesting solution!  The
obvious rejoinder is: how is enforcing "min_date <= max_date" any
easier than requiring that fuzzy_date has the required format?  In
practice, no data manipulation would be done without the use of a fuzzy
date class definition that handles all the validation issues, so I'll
stick with the current (already half-implemented) idea, but it's good
to see y'all thinking outside the box.

The
obvious rejoinder is: how is enforcing "min_date <= max_date" any
easier than requiring that fuzzy_date has the required format?

If you are using a DBMS that supports check constraints the former
is trivial.  E.g. (should work for PostgreSQL--but I didn't test
it):

create table award (
    grantor_id integer not null references member,
    recipient_id integer not null references recipient,
    min_date timestamp not null,
    max_date timestamp not null,
    description varchar not null,
    check (min_date <= max_date)
);

Damn, apparently this site can't handle less-than signs very well.  The important line in my example read



check (min_date less_than_or_equal max_date)



Where "less_than_or_equal" should be replaced by the usual combination of characters.

Rick:

It would make more sense if data was initialized:



String data = new String( new byte[80] );

I doubt that the code was complete so there will be some part in the
source coping with the initialization of data. Anyway what sense would
above line make? Strings are immutable in Java, so execept of more work
to do for the garbage collector initializing data with 80
ASCII-zero-characters using a deprecated constructor has no effect on the functionality of the code.





Regards, Lothar

why don't you just write min_date &lt;= max_date ?

oops, they got me, too

don't be silly, just use < instead

So flat files are indicative of all that's wrong with the heyday of
yesterday?  Hmmm... I'll be sure to tell all my Unix boxes and
they're sad and pathetic relics, bound for the scrapheap.  ;)



Seriously, if I can't have my configuration file for X in a text file,
I'm a very unhappy boy -- there is absolutely no easier way to script
an app.  Dumping everything into a binary file might be efficient
space-wise, but that's about the only respect in which they're superior.

Anonymous:

Drak:

Drop the '-'s and we can talk [:D]

Drak

Use integers instead of strings, it's even more fun.

Integers wouldn't always be the same length. And dates as integers suck.Unless you use the ticks representation (and always use the same ticks representation).

Drak

Reminds of this VB6 function that was written by a cobol-transformed programmer:



function PadZeros(oldString as String, length as Integer) as String

{

    dim i as integer

    dim retVal as String



    retVal =  oldString

    for i = 1 to length

       retVal = retVal & "0"

      

    PadZeros = retVal

}



It's wrong on so many levels!

I have seen this type of thing before...Old cobol code wrapped by Visual Basic COM - wrapped by C# ASP.Net -yak.



We had to write a wrapper around the VB Com object that only has 1
property of type string but the string has fixed positions identifying
certain fields.



Some code snippets....



        public string X_FNAME_OUT {get {return GetField(Field.X_FNAME_OUT);}}

        public string X_FNAME_GEND {get {return GetField(Field.X_FNAME_GEND);}}

        public string X_SNAME_OUT {get {return GetField(Field.X_SNAME_OUT);}}

        public string X_P_ADD1_OUT {get {return GetField(Field.X_P_ADD1_OUT);}}

        public string X_P_ADD2_OUT {get {return GetField(Field.X_P_ADD2_OUT);}}

        public string X_P_ADD3_OUT {get {return GetField(Field.X_P_ADD3_OUT);}}

        public string X_P_ADD4_OUT {get {return GetField(Field.X_P_ADD4_OUT);}}

        public string X_P_ADD5_OUT {get {return GetField(Field.X_P_ADD5_OUT);}}

        public string X_P_PCODE_OUT {get {return GetField(Field.X_P_PCODE_OUT);}}

        public string X_P_SUBCODE {get {return GetField(Field.X_P_SUBCODE);}}

        public string X_P_NGCODE {get {return GetField(Field.X_P_NGCODE);}}



....



private void SetField(Field field, string data)

        {

            int iFieldIndex = (int)field;

            int MaxLength = (int)IValueFields[iFieldIndex, FieldLength];



            data = data.ToUpper();



            switch(field)

            {   

                case Field.X_P_ADD1_IN:

                case Field.X_P_ADD2_IN:

                case Field.X_P_ADD3_IN:

                case Field.X_P_ADD4_IN:

                case Field.X_P_ADD5_IN:

                case Field.X_R_ADD1_IN:

                case Field.X_R_ADD2_IN:

                case Field.X_R_ADD3_IN:

                case Field.X_R_ADD4_IN:

                case Field.X_R_ADD5_IN:

   
           
    data = data.Replace(@"P O BOX", @"PO BOX"); //Fix

                    break;



                default:

                    break;

            }



            if (data.Length > MaxLength)

            {

   
            throw new
IValueWrapperException(@"Data exceeds maximum length of input field " +
field.ToString());

            }



            data = data.PadRight(MaxLength, ' ');

            IValueFields[iFieldIndex, FieldData] = data;

        }



....




            IValueObj.InputStr = this.ToString();


            IValueObj.RunIVJ2CVB();


            ExtractData(IValueObj.OutputStr.ToString());




And the company responsible for this Modern COBOL mess - http://www.intimatedata.co.za/

This makes me want to run for the hills.  [:S]

OK.  All respect to the host but the explanation is a little off.

This code is a Java converting data to and from a copybook retrieved from a Mainframe.  The data format is not the WTF.

The WTF is that instead of defining this class as a collection of field Objects that define the length and type of each field in the copybook and calculate the offsets on loading of the class, the developers copied the basically the same method, with the same local variables, about 500 - 1000 times (There are many classes like this.)  Notice that getCUSTOMER_NBR() doesn't call getRawCUSTOMER_NBR(), it's a duplication of the same method with an extra line of code.

Another WTF is the way repeating records are indexed and retrieved.  Why does it find the field and the add the length of the repeating records to that offset instead of finding the correct repeating record and grabbing the field.

The other WTF is that each of these classes is about 2000 lines long.  Whoever developed this didn't put the methods in the same order as the fields.  That means if any of the fields in the middle of the copy book have to be resized, you would have to go through and search back and forth adding the length of each field to the last and use that to update the offset of three methods for every field.

Anonymous:

Seriously, if I can't have my configuration file for X in a text file,
I'm a very unhappy boy

Config files and databases are very different things.

Anonymous:

So flat files are indicative of all that's wrong with the heyday of yesterday?  Hmmm... I'll be sure to tell all my Unix boxes and they're sad and pathetic relics, bound for the scrapheap.  ;)

Seriously, if I can't have my configuration file for X in a text file, I'm a very unhappy boy -- there is absolutely no easier way to script an app.  Dumping everything into a binary file might be efficient space-wise, but that's about the only respect in which they're superior.

Not sure who you are replying to here but config files are normally not fixed length records like this code deals with.

Mike R:

I am sure there's a very good excuse for this.

Nobody would store all the data to a class in a single string without good reason. If they don't have a good reason, they should be dragged out back and shot.

Co-worker I had once did....

I spent days removing SetBlah(string shootMeNow) functions....and replacing them with properties with the appropriate type (this is C#)

As an added bonus, his code many times resulted in stuff like stringVar.ToString() and other atrocities.

I spent a good couple of years working with a framework like the above.
It was designed to interept a network api for an AS/400 host system.
The protocol was (and still is) a series of fix width buffers passed
over TCP to and from the host.



We had a little tool to generate the classes for each record type,
which link the above had a nuch of getters that accessed the underlying
buffer by sections.



I didn't think it was to bad at the time....having said that if this is hand written then...WTF

gid79:

We had a little tool to generate the classes for each record type, which link the above had a nuch of getters that accessed the underlying buffer by sections.

I didn't think it was to bad at the time....having said that if this is hand written then...WTF

Thank you.  Someone gets it.

Not only is it hand written, it's copy and paste code.  They could have at least defined a class for each field such that the offsets could be automatically determined from the lengths of the fields.

Interesting to see the comments on this piece of code since (unless there is an astounding coincidence) it is part of an application that I worked on.  A few of you got it sort of right, though not entirely.  It is output from a program that reads COBOL copybooks and generates Java classes which understand the format described by the copybook, and can read or write strings in that format.  The field names are taken directly from the copybook, thus the uppercasing.  Of course it could be done better, but in the scheme of things it was written for a company whose core business is not producing software or even close to it, so spending more time building the perfect code generator was not funded (and in 1998 when this was written there were no products on the market for it).  The more annoying WTF is that I see people still using this program and then hand tweaking the generated code, insuring later breakage if it is ever regenerated.  Anyway, highly amusing to see it mentioned here.

Anonymous:

Interesting to see the comments on this piece of code since (unless there is an astounding coincidence) it is part of an application that I worked on.  A few of you got it sort of right, though not entirely.  It is output from a program that reads COBOL copybooks and generates Java classes which understand the format described by the copybook, and can read or write strings in that format.  The field names are taken directly from the copybook, thus the uppercasing.  Of course it could be done better, but in the scheme of things it was written for a company whose core business is not producing software or even close to it, so spending more time building the perfect code generator was not funded (and in 1998 when this was written there were no products on the market for it).  The more annoying WTF is that I see people still using this program and then hand tweaking the generated code, insuring later breakage if it is ever regenerated.  Anyway, highly amusing to see it mentioned here.

I know of no code generator for this and it's part of a subsystem that is completely unstable and unreliable.  Messages produced by it have taken weeks to find their recipeint.  I find it unlikely that it will be regenerated, especially not to add one field.  It's more likely be relegated to the trash bin.

This is why I find the thread amusing, it just highlights that code can look silly if you don't know it's background or context.  That you didn't know this is from a generator is a perfect example.  I mean the comments about this being written by a cobol developer, or trying to align on word boundaries etc.. lol.  Don't get me wrong, the code has some definite issues but it is more along the lines of poor handling of txn versions and field redefinitions.  Feel free to fix it :)

x22288

Anonymous:

This is why I find the thread amusing, it just highlights that code can look silly if you don't know it's background or context.  That you didn't know this is from a generator is a perfect example.  I mean the comments about this being written by a cobol developer, or trying to align on word boundaries etc.. lol.  Don't get me wrong, the code has some definite issues but it is more along the lines of poor handling of txn versions and field redefinitions.  Feel free to fix it :)

Perhaps you are right.  Sometimes frustration gets the best of me.  Not being able to fix the issues that plague me is frustrating.

I guess the real WTF is not having the generator anymore.

Out of runes of magic gold? Need it in urgent? Yes, I can understand you. As the most important currency, without rom gold, you ever can’t do anything. So you need to buy rom gold from those most professional and loyal game online shops with years’ experience and have a good reputation among players. Is there any difficult? No, when you need the rom gold, please feel free to contact us, we are promising to offer you the cheap runes of magic gold with fastest delivery. Moreover, we are online 24/7, you can contact us any time with any question about. So why are you still irresolute? Come here to grab your cheap runes of magic gold now. Crazy about running warhammer gold? Yup, it is so crucial indeed for us in Warhammer Online. Without it, we can even do nothing, without money to buy items, weapons and so on. So enough warhammer gold is substantial.