Just a sample of what I'm dealing with.

Control ctrl = (Control)sender;

switch (ctrl.Name)
{
case "cboCustomer":
.
.
.


Seriously, WTF? There's 2 events like this... I could have been 
mistaken, but I thought the great advantage of events and such was to 
avoid switch statements, or long if...else... blocks.

I've actually counted as many as 3 different places where data is loaded 
into controls from the currently selected item.

I have 1 "form" (actually it's a user control) that contains some basic 
data, and is in 4 files, approximately 4,000 lines of code each.

It's painful.

Oh, and get this... the database is just as delightful. The customer's 
address information is in..... 3 tables.

1 the main table contains the address itself, and pointers to the city, 
and the state tables.

That's right, a row for every city, and a row for every state.

It's more than just that. The address was just the easiest to explain 
example of the wtfery that permeates this project.



-- 
~Mike

Post a reply to this message

Mike Raiford schrieb:
> Control ctrl = (Control)sender;
> 
> switch (ctrl.Name)
> {
> case "cboCustomer":
> .
> .
> .
> 
> 
> Seriously, WTF? There's 2 events like this... I could have been 
> mistaken, but I thought the great advantage of events and such was to 
> avoid switch statements, or long if...else... blocks.

Is that C# code?
Then it's probably just one more case of grown code, such as:

- Events X from control A and Y from control B must trigger the same 
action, so we'll just route them to the same code.

- Hey folks, we need to do some extra action when X is raised by A; make 
sure you get this up and running before the next release... oh, and that 
would happen to be in two hours' time, so you better skip your lunch 
break today.

- Duh, no lunch today? That's bad. Let's see how we can fix this with as 
little time effort as possible...


That's what happens when people aren't given enough time (or are too 
lazy) to refactor their code now and then.


> Oh, and get this... the database is just as delightful. The customer's 
> address information is in..... 3 tables.
> 
> 1 the main table contains the address itself, and pointers to the city, 
> and the state tables.
> 
> That's right, a row for every city, and a row for every state.

That doesn't sound particularly WTF'ish to me. Unless, of course, the 
city and state tables contain one row for each customer (in that case: 
Good thinking on the part of the database designer, but probably bad 
communication with the guys who implemented the application) or use the 
city / state name as their primary key and only data column...

Post a reply to this message

Mike Raiford wrote:
> That's right, a row for every city, and a row for every state.

Sounds very Enterprise to me.  Helpful if you want to assign salesmen to 
regions and stuff like that.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Le 06/08/2009 23:05, Darren New nous fit lire :
> Mike Raiford wrote:
>> That's right, a row for every city, and a row for every state.
> 
> Sounds very Enterprise to me.  Helpful if you want to assign salesmen to
> regions and stuff like that.
> 
Sounds also a good schema: no repetition of long shareable data.
May be a bit too optimised.

And easier update next time south-dakota decides to have a new name too.
New-Orleans... nah... call us Atlantide from now on!

Post a reply to this message

Le_Forgeron wrote:
> Le 06/08/2009 23:05, Darren New nous fit lire :
>> Mike Raiford wrote:
>>> That's right, a row for every city, and a row for every state.
>> Sounds very Enterprise to me.  Helpful if you want to assign salesmen to
>> regions and stuff like that.
>>
> Sounds also a good schema: no repetition of long shareable data.
> May be a bit too optimised.
> 
> And easier update next time south-dakota decides to have a new name too.
> New-Orleans... nah... call us Atlantide from now on!

More importantly, it helps keep you from accidentally spelling the name 
wrong during data entry (or lets you provide a drop-down list or whatever), 
thereby ensuring data consistency.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

"Mike Raiford" <"m[raiford]!at"@gmail.com> wrote in message
news:4a7b1abd$1@news.povray.org...

> Oh, and get this... the database is just as delightful. The customer's
> address information is in..... 3 tables.
>
> 1 the main table contains the address itself, and pointers to the city,
> and the state tables.
>
> That's right, a row for every city, and a row for every state.

It sounds bad: The city table should include a foreign key to the state
table instead of main table referencing both. Better yet, there should be a
street table that actually points to the city table which points to the
state table. <g>

Post a reply to this message

> 1 the main table contains the address itself, and pointers to the city, 
> and the state tables.
>
> That's right, a row for every city, and a row for every state.

That seems fine to me, for one thing it avoids people making a typo on the 
state, which makes doing things by state harder later on.  Not so sure about 
the city, I don't know how it works in the US, but in the UK you might not 
officially be living in a city, and then your "city/town/village" table is 
going to be HUGE with basically every little place in it, and there are 
duplicates in different parts of the country!

Post a reply to this message