|
Not the first horror of this type. I think that VB .NET programmers miss a RegardlessOf keyword. Usage:
RegardlessOf boolean-expression
a code block which is always executed
End RegardlessOf
Greetings - Jacek
modified 18-Dec-11 9:34am.
|
|
|
|
|
A "whenever" keyword? What, is that for even simpler declaration of event handlers than VB already has?
|
|
|
|
|
I used a wrong word, it should be "regardless". I knew that sth was not right, thanks.
Greetings - Jacek
|
|
|
|
|
IMHO RegardlessOf is a very good choice you made. Especially when it's syntax would be RegardlessOf( condition ){ ... }
Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
It also needs
AsIf unmeetable-condition
a code block which can never execute
End AsIf
|
|
|
|
|
I'm lovin' it! Put it right next to DoNothingWithThese(variable parameters). 
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
and that essential scope modifier, "Unused"...
as in
public unused Boolean FlagSomething = false;
|
|
|
|
|
Our students have to take basic skills exams, they are essential to getting th degree, so these tables are important. Unfortunately, the Database design looks like it was written by a gorilla mashing the keyboard. And The gorilla was not happy with the world. So far I've found:
0) A bool/bit column that never has a non-true value, and a text column with the same text in each row.
1) A date column, and a column next to it with the day of the week (Monday, Tuesday etc) as text.
2) A table that holds exam sessions with capacity and the number of students enrolled. Why is this bad? Because we have a table relating students enrolled to each session, so the real attendance is the count of those and not some needless, brittle, maintained value.
3) Two tables that define whether a student has enrolled to a skills exam. The student is always present in the first with a boolean "Enrolled", but only present in the second if they have enrolled.
The worst thing is I can't even fix it: I don't know what else sits on it. I do have the code I'm replacing written, badly, in VB.NET which is also self-obstifucating and has Database work in the UI. They didn't get the database stuff right either: the inserts which enroll a student aren't in a transaction so if anything goes wrong the database will be in an invalid state.
|
|
|
|
|
And would that be an Access database?
It reminds me of a monstrosity whose schema was unprintable using 4 A3 sheets, with many many tables that were basically simple projections (ie one table for SELECT Name, Address FROM Customers, another for SELECT Name, Phone FROM Customers), instead of using views or queries...
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
Keith Barrow wrote: Database work in the UI
So there should be no problem.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
None of those beat something create by 'experts', like the disabled attribute for HTML elements that has the value 'disabled' to disable an element and is completley absent to enable an element.
|
|
|
|
|
Hahaha, yeah...I had a good laugh when I read this. Just a couple weeks ago I was trying to figure out why my disabled HTML elements were disabled in some browsers but not in others. Turns out not every browser likes the more sensible disabled="true" (although some did, hence my confusion). I've been living in XAML land too long 
|
|
|
|
|
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:
<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?
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.
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
