![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Mike Raiford
Subject: The code I'm working on makes me want to cry ...
Date: 6 Aug 2009 14:02:37
Message: <4a7b1abd$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: The code I'm working on makes me want to cry ...
Date: 6 Aug 2009 17:05:19
Message: <4a7b458f$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Le Forgeron
Subject: Re: The code I'm working on makes me want to cry ...
Date: 6 Aug 2009 17:15:53
Message: <4a7b4809$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: The code I'm working on makes me want to cry ...
Date: 6 Aug 2009 19:27:05
Message: <4a7b66c9$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: somebody
Subject: Re: The code I'm working on makes me want to cry ...
Date: 7 Aug 2009 00:21:33
Message: <4a7babcd@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |