The Weird and The Wonderful

It's not useless, though. You can draw a disabled text-box for style reasons with this attribute, and make it copyable in a more convenient way than simply rendered HTML.

Oh dear.

It's not being able to disable an input I find stupid, but the way the "disabled" attribute, with only one possible value, is used.

Yeah, but remember, before xhtml came around, it was used like:

HTML

<input disabled>

which makes a lot of sense.

Sounds like a massive pain in the arse. Good luck with it!

I love this: self-obstifucating.

Make the Database redesign.. THE basic skills exam!! Get a group of Computer Science students on the case 2 birds 1 stone BAM!

Hmm... I have been working with relational databases for 15 years and....
I have been guilty of all the things you mention at one time or another.

Yes, there are certain standards that are accepted but... when you have to make a database system work in a real live enviroment... sometimes things that seem rather absurd really make a lot of sense. These things are often done in order to improve proformance or to allow data from a legacy system to be used. Storing data/sums/calculations in a table can improve proformance if the they seldom change and you have a good way to batch update these values during off hours.(or just calculate them once when the record is created not everytime anyone wants to view that data) I have used an always true bool/bit value in some systems in order to relate all values from one table to another(although it has seldom been required in recent years as the tools have often changed to deal with this).

The biggest problem with doing these things is not that they don't work (often these things make the system run better... sometimes a lot lot better) but because if you don't know why something was done, it is hard for anyone else but the designer to safely change anything and can become a maintaince nightmare. (and without the designer or someone very famillar with the system... it might be better to throw it all out and start over with the basics... a long hard road)

This post was written by a gorilla mashing the keyboard.

modified 16-Dec-11 13:04pm.

Redundancy for performance reasons is in most cases a bad argument. You use redundancy in the database when you have some batch update which would otherwise be impossible or very comutation-intensive. But most apps of the type described in the original post only work with a few records (well, maybe a few dozen records) at a time, and use few and uncomplicated aggregations. In such cases redundancy only slows down inserts and makes the database more dificult to maintain.

Also, nowadays, when they deliver acceptable performance, you absolutely should use ORM tools/libs, instead of hand-crafting your persistence (which doesn't necessarily mean you have to let the ORM lib maintain your DB schema, but this is sometimes useful too - when the schema changes often, it's simpler to let the ORM handle changes instead of managing them yourselves, and it pays off, as long as performance stays acceptable). When using such tools, a non-normalized database schema, using const columns, is plain stupid.

While I agree that the database design is less than optimal point number 2 might actually be a good database design (despite who implemented it).

There are a lot of times that information is duplicated in other records because it's that important for the smooth running of the system. Lets take the number enrolled students and consider what happens if someone removes one student from the database.

First if you were just counting the number of records then anyone accessing the records would have the results change on them and if you are running KPI's or any sort of reporting function over this information it will lead to inconsistant information from the system (i.e. you print a report last week and it says x students attended exams and this week it says y you then go WTF).

Secondly from an auditing point of view there are probably legal or regulation requirements on keeping track of the number of students attending exams (assuming the processes keep that information up to date) and once that information is entered it's locked. A great example is tax. Would you like it if the tax that gets taken out of your pay to be a calculated value? 'Hey Keith I know you did a bit of overtime this week so your tax rate went up, oh and by the way you won't get paid next week because the tax department says you have an outstanding amout that you owe them.'.

The last reason is if there are two fields that are supposed to hold the same information but don't then people will start asking a lot of questions. Since this will occur immediately after a process has failed you have the ability to trace the issue while people can still remember what they have been doing recently. Trying to track down a problem way, way after the time it has occured it a real pain in the butt.

PS: I feel your pain but I've had to 'upgrade' a few critical systems built in access where code for directly changing the database was embedded in each form and if there was two processes for entering information then there was two different forms with the code copied and pasted. Trying to reduce it to one logical process was interesting since there were a lot of if statements with multiple places where it reads and writes to the database was ..... interesting.

I found this gem of a code when I was reviewing some code I am supposed to enhance. And this kind of conversion code has been used all over the project. Note that variable and method names have been changed.

Did the guy who wrote this code ever have any idea how much memory and processor cycles does throwing and catching exceptions entail?

C#

int age;
string strAge = GetAge();

try {
    age = Convert.ToInt32(strAge);
} catch {
    age = 0;
}

modified 13-Dec-11 23:42pm.

It was VERY common prior to .Net 2.0 which introduced the TryParse methods. There really wasn't a 'good' way to do this, so if the result of GetAge() was normally a valid number, then it wouldn't hurt performance much. The performance hit is only noticable if there is actually an exception thrown.

GibbleCH wrote:
The performance hit is only noticable if there is actually an exception thrown.

Exactly. And when I was debugging, it was indeed throwing exceptions at many places because the values were supposed to be coming from a missing configuration element.

Shameel wrote:
how much memory and processor cycles does throwing and catching exceptions
entail?

Maybe, but perhaps you don't?

Performance implications of Exceptions in .NET[^]

The idea was to convey that a mere check for numbers would have been enough in this case instead of relying on .NET's exception handling to assign default value for missing items (and unnecessarily create and dispose exception objects). And when I was debugging the code, it was throwing exception all over the places because the values were supposed to come from config elements which were missing. It's a bad practise even from a debugging perspective.

Shameel wrote:
a mere check for numbers

That's worse; it can still go wrong, a string of "9999999999999999999999999999999999999999" for instance. Using a built-in method is much simpler and if you have to protect against Exception, then do so, it doesn't cost anything.

Sounds like you didn't RTFA:

"Only primitive string processing was affected by raised exceptions"

I'd describe a conversion from an string to an int as fitting that description.

Generally, however, I agree - people are too fixated with the costs of exceptions. If there's any I/O going on at all, its negligible.

Shameel wrote:
atrAge

Shameel wrote:
strAge

I think I see the problem!! Laugh | :laugh:

Silence is golden... but duct tape is silver!!

Booger Mobile - My bright green 1964 Ford Falcon - check out the blog here!! | If you feel generous - make a donation to Camp Quality!!

That was just a typo. I renamed the variables to save the identity of the culprit. Smile | :)

Shameel wrote:

That was just a typo. I renamed the variables to
save the identity of the culprit.

I know... it was funny though!!

Silence is golden... but duct tape is silver!!

Booger Mobile - My bright green 1964 Ford Falcon - check out the blog here!! | If you feel generous - make a donation to Camp Quality!!

This isn't bad, just outdated. Before the introduction of TryParse this is basically how you had to do it (though I would use int.Parse not Convert.ToInt32, but one calls the other I think). Although you could argue it should be in a single utility method, it's only a couple of lines so it's hardly worth it.

A try block uses almost no resources, and the exception will only be thrown when the requested string isn't a valid number, so I doubt there's any noticeable performance impact from doing this.

Annoying to deal with when you have a better solution available to you now, and you have debugging set to look at caught exceptions? Yeah, probably. But it's not really bad code. If you're complaining that the debugger stops on it, try adjusting your settings – otherwise you can use that as an argument against any catch blocks and I'm sure you can see how that becomes an absurd position to hold pretty quickly.

10!

BobJanova wrote:
one calls the other

Yes, Convert calls the specific class' method, Int32.Parse in this case -- that's why I tell people not to use Convert.

modified 15-Dec-11 11:18am.

BobJanova wrote:
you have debugging set to look at caught exceptions?

yes, I have to do that to handle some subtle exceptions that are caught and swallowed (empty catch blocks - now that deserves a separate post by itself).

BobJanova wrote:
try adjusting your settings

I hate to keep doing it every now and then to accomodate this kind of code. Unfortunately, for now, I have to live with it since I cannot change the behavior of existing "working code".

But my point is that 'this kind of code' is basically any code that uses exceptions.

Swallowed exceptions generally deserve a post here, yes. This code handles the exception to put the variable into a valid state so it's not in the same category.

Perhaps better than changing your settings would be to make the config file valid.

An app I support interfaces to a large number of 3rd party webservices. Often the documentation is poor or incomplete. Last week I integrated to one that seemed pretty well documented. At one point it says

xxxxxx can be called in one of four modes:
● Redirect (default)
● XML
● JSON
● iFrame
The mode can be specified by setting the 'mode' query string parameter

and subsequently refers to "XML mode" several times. I coded up the interface, ran some tests; and got non-specific errors every time. Eventually the 3rd party company got back to me with the following explanation:

mode=XML should be mode=xml i.e. the "xml" is case sensitive.

It works now but it's wasted two hours of my time and delayed the integration by the best part of a week.

TEST THE DOCUMENTATION TOO, YOU WALLYS!

Agreed...but how does 2 wasted hours delay integration nearly a week?

If does when they don't reply to your query for 5 days!