|
Once had the great pleasure of having to examine our banks End of Day processor.
part of the app had the ability to show the account transaction records, which they used to dump transactions to luvly excel spreadsheets for analysis....
the guy who wrote it obviously had never heard of SQL joins though
he used a SQL statement along the lines of "Select * from tran" to retrieve all the records, then entered into a mother loop.
for each row in result<br />
for each column in the result<br />
if the datatype is a int, it must be a foreign key <br />
do a whole load of messin to work out the foreign key table<br />
so do another sql statement to pull back the foreign key value from another table<br />
output the foreign key value<br />
else<br />
output the value<br />
end if<br />
next column<br />
next row.
worked out that each time a new transaction was entered onto the system this loop would have to do another 60 or so new SQL requests.
so instead of one sql query using multiple joins to get foreign key values, this numpty wrote over 60 queries, which fired for each and every row output.
and considering this was only a weeee bank, We did only have in the region of 5 million transactions with about another 100,000 or so a month getting added..
and they wondered why it could take ages to display only a few hundred thousand records and output them..........
|
|
|
|
|
Once upon a time, I had to maintain an MS Java application (first shame). In this application, threads were synchronized using the window-based interface.
At the start of a task, a thread was given a reference to a label. The thread was started and changed by itself the text property of the label to some kind of status. In the "textchange" event of the label, the text was checked. If it equalled "100%" another thread was started following the same pattern.
/Zorbek
|
|
|
|
|
I develop software to control scientific instruments. This is a different world to databases or financial software. The first rule is to insist on the electronic and mechanical designers proving that the hardware is working properly before you will consider that the software has a bug. (The first rule of the mechanical and electronic designers is, of course, "the software is faulty"). The second rule is that just when you've got it all working properly they will change the hardware.
I once worked on software to control a mass spectrometer. This detects a particle beam travelling down a vacuum tube. There were two types of detectors, the instrument could either be fitted with "high detectors" or "low detectors".
I was looking through the source one day when I came across this user error message (without the stars of course).
"Both high and low detectors fitted. B******S, THEY PROMISED ME THIS WOULD NEVER HAPPEN."
Regards
- Roger
|
|
|
|
|
That was hilarious. Thanks for sharing.
A friend is, as it were, a second self.
- Marcus Tullius Cicero
|
|
|
|
|
NOT SO FAST !!!!
Okay you think this is just horrible, and 99% of the time I would agree with you. However, let me explain my experience with this exact situation. I worked at a company where we had the usual daily meeting. The guy sitting next to be asks our manager about a request he's working on. The question went something like:
"This process compares records in out database to the client file and performs calculation "A" which is saved to our database. So, what do you want me to do if a client record cannot be matched up to an record in our database?"
To which the manager said, that will never happen. Being the logical programmer my buddy replies, "but what if it does happen?" To which Mr. Stubborn manager replies, "I just told you that it will NEVER happen.
Hence, the origin of the error message. Given the circumstances, wouldn't you cut this guy some slack?
|
|
|
|
|
It wasn't flagging the situation that I thought was the problem, but calling his colleagues b******s in a message that would be displayed to the users.
By all means write it to an internal log file or something, but don't swear at the users, it's not very professional.
Regards
- Roger
|
|
|
|
|
Color me stupid, I thought the b*****s was the person's name. Note, my initials are B.S. In my case, the manager's name was put into the message replacing the b******s.
Now that i understand your true meaning...
I have a client who is paying top price for a website face lift. I was doing an A/B compare on the test release of the site in FireFox and IE. I must admit they did a good job with absolutely no difference between the two browsers. Curious as a cat, I decided to view the source code in hopes of getting the link to their Java Script file and any style sheets for future reference. Paging down in the source i found a hidden DIV where a developer left a large does of his explicitive filled comments regarding the client. HOLY-COW! I couldn't believe what i was reading, and can't repeat any of it here.
Regardless, it's all pretty funny stuff.
|
|
|
|
|
...so read an error message I found in a customer's code a while back.
Needless to say it didn't last long once I found it!
|
|
|
|
|
I found a TODO: handle string thingie in some code the other day..until today I STILL don't know what the author ment to say
To reassure you, I long promoted that function to the recycle bin.
|
|
|
|
|
///
/// Fuegt solange Blanks an den String an, bis die
/// Laenge length erreicht wird.
///
/// <param name="inputString" />
/// <param name="length" />
/// <returns>
public static string AddBlanks(string inputString, int length)
{
string outString = inputString;
while (outString.Length < length)
{
outString = outString + " ";
}
return outString;
}
Not only a memory issue (using string instead of stringbuilder), but why have the gods^W BCL group created the string.PadRight(lenth, ' ') method?
What do you think?
Cheers,
Juergen
|
|
|
|
|
6o`clock wrote: Not only a memory issue (using string instead of stringbuilder), but why have the gods^W BCL group created the string.PadRight(lenth, ' ') method?
What do you think?
I would think someone is learning C#.
I can see me making mistakes of exactly the same type.
Ok, I know about stringbuilder, but there are whole top-level namespaces I never used. I certainly do not know their functions by heart.
Failure is not an option - it's built right in.
|
|
|
|
|
My colleague and I had an interesting discussion about this. According to us, there are two types of programmers out there. The first type thinks 'This is such a common thing to do, someone MUST have included it' and therefor ends up using the PadString method. The second type just churns away without seconds thoughts and ends up with the originally posted code.
The funny thing is that 9 out of 10 times people tend to refactor these snippits into a utilities class, calling the method 'PadString'
|
|
|
|
|
...so lets make it global.
This was the answer of a "Technical Consultant" that I worked with many years ago. All of his loops were for i = 1 to 10 next i. This was VB 3 - so some time ago!
To save himself the effort of dim i as integer at the beginning of every function he wanted to use "i" he just made it a global. I can't blame him too much - he was a COBOL programmer who had made the leap to VB.
It made for some surprisingly subtle bugs! Needless to say that I removed it after having to try quite hard to show him the benefits (I was a junior C++ programmer at the time).
|
|
|
|
|
We must have worked with the same guy! I once worked on a VB program with a couple of hundred global variables. When i complained to the original developer he said, "What's wrong with that?"
Funny, this guy was an author of multiple VB books.
Bill Selznick
Bits 2 Systems LLC
bselznick@bits2systems.com
|
|
|
|
|
many years ago I saw the same years ago in a FORTRAN prog, as you say some of the bugs this introduced were interesting. Perhaps this guy used to work in England?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for - in order to get to the job you need to pay for the clothes and the car, and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
|
|
|
|
|
Had this man not heard of DefInt ?
(Worst keyword ever - except perhaps As Any !)
|
|
|
|
|
|
Hello, love the show, long time listener, first time caller.
One of the company's c++ coding guidelines is that goto's are forbidden. For some developers who use goto statements as error handling this could present a problem. For others, ...
for ( ;; ) {
for ( ;; ) {
bool someError = func();
if (someError) {
break;
}
if (anotherError) {
break;
}
break;
}
for ( ;; ) {
break;
}
break;
}
After stumbling upon this beauty I searched and found over 200 infinite loops used as an error handling technique. Not one of these loops ever actually looped.
|
|
|
|
|
Yep, seen it. I hate this irrational ban on goto. It's out of date - it dates from a time when decent control structures weren't common. A judicious, careful, occasional use of a goto is fine. Subverting a control structure to give it a different meaning is definitely not.
For more, see Gotos Considered Harmful and Other Programmers' Taboos[^] [PDF, 17k].
|
|
|
|
|
Goto's are really really bad and should be super rarely used. They are not needed for error handling. The only good use I've seen for goto's is machine generated code with tools like YACC and LEX.
Generally speaking, break, continue, and multiple returns can cause problems too. Readability and maintainability are very important.
Imagine if you will a "come from" statement. You put a label X somewhere then in a totally different part of the method you place a "come from" label X. Whenever control reaches the label you goto the "come from". Imagine how hard it would be to read that code.
What's wrong with using exceptions for error handling?
|
|
|
|
|
RodgerB wrote: Goto's are really really bad and should be super rarely used. They are not needed for error handling.
This
if (spin_trylock(&tty_lock.lock))
goto got_lock;
if (tsk == tty_lock.lock_owner) {
WARN_ON(!tty_lock.lock_count);
tty_lock.lock_count++;
return flags;
}
spin_lock(&tty_lock.lock);
got_lock:
WARN_ON(tty_lock.lock_owner); seems pretty well justified for me.
You could do this with nested if s, but you would neither get more clarity nor faster code. Only code indenting out at your right screen margin.
Failure is not an option - it's built right in.
|
|
|
|
|
I guess we could argue this back and forth. It comes down to avoiding mistakes and doing things as a matter of policy.
E.g.
I never do this:
int* y, z;
I always do this:
int* y;
int z;
Why you ask. Too easy to read it wrong at a glance, too easy to miss something. Some logic as to why I never use goto's and why I don't put returns anywhere but at the very bottom or very top of a function.
I believe this to be more than just a matter of style.
|
|
|
|
|
That is an excellent paper! I rarely use goto , but sometimes it is the best solution to a problem. (Example: escaping from multiple nested loops.)
I once read someone’s general rule that you always go forward, but I found one exception years ago:
NEXT_BYTE:
if( x>xmin ) {
Byte = *(--vptr);
if( Byte == 0xFF ) {
x -= 8;
goto NEXT_BYTE;
}
}
Sure the above code could be written using a loop and originally was, but this increased the speed (graphics code) enough to justify its use at the time.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I once came across an Access database (already WTF) that used columns instead of rows for a Calendar like application ! The Calendar table had (from memory) 1 row for each day with 50+ columns for each half hour block from 8:00am. Now you can imagine the horror it was to try to maintain such an application. The reports that ran of this dog were nightmarish, even to SELECT a single day that had 'something' happening on it looked something like
SELECT * FROM Calendar WHERE Time800 <> '' OR Time830 <> '' OR Time900 <> '' .. OR Time1600 <> ''
I can imagine what the coder would have said when asked to make the days start a little earlier than 8:00, "Oh, sure, that'll take at least another 4 months to re-schema the database and touch up all the affected queries".
And when the original developers were sacked for taking way took long and we took over the project we were questioned why we were completely rewriting it from scratch. The above Calendar table was just one example in this diseased rats nest, there were plenty of others like using hidden form controls as global variables. You would open up the main form and had absolutely no hope of actually telling what it would look like when run since it was completely covered in these demons from hell. I just hate with a passion code that does not read simple, I hate it when I cannot confidently make a simple change to some code without it screwing up something completely unrelated because the variable I modded was global and had different meanings depending on where it was called from.
Anyway that's my rant
Code should be simple. No excuses.
|
|
|
|
|
Steve Fillingham wrote: 1 row for each day with 50+ columns for each half hour block from 8:00am
More than 50 half hours after 8am? Which planet was that calendar designed for - mercury or venus?!?
|
|
|
|