The Weird and The Wonderful

The Weird and The Wonderful forum is a place to post Coding Horrors, Worst Practices, and the occasional flash of brilliance.

We all come across code that simply boggles the mind. Lazy kludges, embarrassing mistakes, horrid workarounds and developers just not quite getting it. And then somedays we come across - or write - the truly sublime.

Post your Best, your worst, and your most interesting. But please - no programming questions . This forum is purely for amusement and discussions on code snippets. All actual programming questions will be removed.

Dear VB6

Nagy Vilmos24-Mar-14 10:25

Nagy Vilmos

24-Mar-14 10:25

Die! Die! Die!

I won't bother with the code, it's all the same. Sigh | :sigh:

Re: Dear VB6

BillW3324-Mar-14 10:51

BillW33

24-Mar-14 10:51

Sorry, I have to disagree; some code is much worse that others. Sigh | :sigh:

Just because the code works, it doesn't mean that it is good code.

Re: Dear VB6

Kornfeld Eliyahu Peter24-Mar-14 11:15

Kornfeld Eliyahu Peter

24-Mar-14 11:15

NV: Die! Die! Why won't you die?... Why won't you die?
VB6: Beneath this mask there is more than flesh. Beneath this mask there is an idea, Mr. Nagy, and ideas are bulletproof.

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Re: Dear VB6

Rob Grainger31-Mar-14 2:16

Rob Grainger

31-Mar-14 2:16

Wow, that was a bit strong. Nagy isn't alone in his opinion of VB6, luckily it won't be much longer before it gets to its final resting place.

"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.

Re: Dear VB6

Kornfeld Eliyahu Peter31-Mar-14 2:25

Kornfeld Eliyahu Peter

31-Mar-14 2:25

I've had very bad experience with VB6 and don't mind to dance on it's grave - sooner is better...
But I do not blame VB or VB6 or VB.NET per se - in my experience it always related to human error (bad choice in most case)...

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Re-using variables can be dangerous

kmoorevs21-Mar-14 9:14

kmoorevs

21-Mar-14 9:14

Re-using variables can be dangerous. The following code had me baffled for hours. This code queries a dozen different XML files on the server, builds a response, and serves it to different dashboards.

fileName = "FinSummaryByMonth";
xmlFile = Server.MapPath("Data/" + DistrictNumber + "/" + sYearFolder + "/" + fileName + ".xml");
srcDoc = XDocument.Load(xmlFile);
//linq to xml process 1...should build 13 rows with 12 elements...OK
//append to the buildDoc and move on to the next section

fileName = "MealSummaryByMonth";
srcDoc = XDocument.Load(xmlFile);
//linq to xml process 1...should build 11 rows with 12 elements...WRONG! returning 13 rows!

Being a newbie to linq, I had assumed the mistake was in the query. 2 hours later, looking at the output, I realize that the rows in the problem section were identical to the rows in the previous section nevermind that the results should have been ints. D'Oh! | :doh:

"Go forth into the source" - Neal Morse

Re: Re-using variables can be dangerous

PIEBALDconsult21-Mar-14 9:21

PIEBALDconsult

21-Mar-14 9:21

"Omit needless local variables." -- Strunk... had he taught programming

Or, better, write a method and eliminate the repetitive code.

You'll never get very far if all you do is follow instructions.

Re: Re-using variables can be dangerous

robocodeboy24-Mar-14 1:23

robocodeboy

24-Mar-14 1:23

PIEBALDconsult wrote:
Or, better, write a method and eliminate the repetitive code.

This.

Re: Re-using variables can be dangerous

kmoorevs24-Mar-14 10:06

kmoorevs

24-Mar-14 10:06

Good advice! I suppose I could stick the file names into a list with any parameters distinct to each query and return a loaded XDocument or Array. Maybe in the next version! Thanks! Smile | :)

"Go forth into the source" - Neal Morse

This code base is the gift that just keeps giving

Rob Grainger12-Mar-14 23:59

Rob Grainger

12-Mar-14 23:59

Yes, I'm back with yet another gem from the the VB hell I'm porting:

' RJG: Best name ever.
Private Sub LoadGrid()
    Dim SQL As String
    Dim x As Long
    Dim rst As New ADODB.Recordset

    txtMode.Text = mode
    txtPID.Text = PID
    txtPolTypeID.Text = policytypeid
    x = Val("" & txtPID.Text)
End Sub

That comment wasn't there, that was my contribution!
This is fairly typical of the code quality - note that..

1. The name is unrelated to the procedure.
2. There are two local variables that are dead.
3. It loads a text box from an integer field (PID is an Integer), but still feels in necessary to prepend "" in the last line, just in case!

They're wondering why it's taking me a long time to port. Can't imagine.

<Edit>And of course I forgot to mention that both txtPID and txtPolTypeID are hidden fields, with OnChange event handlers that carry out further processing - flow-of-control in this application is fractal-like.</Edit>

"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.

Re: This code base is the gift that just keeps giving

Brisingr Aerowing18-Mar-14 14:52

Brisingr Aerowing

18-Mar-14 14:52

I feel your pain. That codebase must be like Cry | :((

at times.

What do you get when you cross a joke with a rhetorical question?

Re: This code base is the gift that just keeps giving

Kornfeld Eliyahu Peter18-Mar-14 21:10

Kornfeld Eliyahu Peter

18-Mar-14 21:10

Rob Grainger wrote:
VB hell

Why VB. It's a hell of non-programming, but not because of VB but because of the men wrote it...

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Re: This code base is the gift that just keeps giving

Rob Grainger19-Mar-14 0:27

Rob Grainger

19-Mar-14 0:27

Because this particular hell was constructed in VB. I've seen plenty of JavaScript hell too (and many others), but VB seems to particularly attract the infernal.

"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.

Re: This code base is the gift that just keeps giving

Kornfeld Eliyahu Peter19-Mar-14 0:55

Kornfeld Eliyahu Peter

19-Mar-14 0:55

I done VB development of very large scale application (Microsoft sold us that VB is the language of the future). We done it in VB6 using every dirty trick we found - still the code was well written and readable...The application went off at 1999 and still working...

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Re: This code base is the gift that just keeps giving

Gary R. Wheeler22-Mar-14 1:46

Gary R. Wheeler

22-Mar-14 1:46

I feel your pain Rob. I've spent the last three weeks on a refactoring job that was supposed to last two days at most. The guy who wrote the original code was pretty sharp, with a deep background in embedded development in C. Unfortunately, the code in question is for a Windows service written in C++. Unsafe pointer casts everywhere, no attempt to follow the group naming convention, class member variables that were unused, lots of pointer arithmetic rather than straightforward array indexing, locals that were initialized and never referenced, the list goes on. The worst was the mix of MFC and STL collection classes. I spent four days alone getting the thing to shutdown without throwing exceptions or locking up due to threading issues.

Software Zen: delete this;

Re: This code base is the gift that just keeps giving

Rob Grainger23-Mar-14 6:42

Rob Grainger

23-Mar-14 6:42

In many ways I suspect that's worse - at least VB doesn't tend to just bomb when an error occurs (at least while debugging) - in C/C++ unhandled exceptions tend to be, well, fatal.

I don't envy you.

"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.

Re: This code base is the gift that just keeps giving

Henry Skoglund24-Mar-14 11:56

Henry Skoglund

24-Mar-14 11:56

Agreed, porting someone else's c++ can be one step closer to the insanity abyss (compared to VB).

When i did a port/rewrite, it felt like peeking into that other fellow's brain, wondering how he could function with that strange wiring of his brain. I remember he used to start for example an event loop with a delete xxx call (except if it's the first time) followed by a new xxx call...

A new low in in-line SQL

Duncan Edwards Jones12-Mar-14 7:40

Duncan Edwards Jones

12-Mar-14 7:40

Not only does the SQL query get assembled by string concatenation but yes indeed - there is even a bit of it commented out ...in the SQL concatenation string....

Quote:
"" + _
"/* " + _
",( " + _
" SELECT " + _

Re: A new low in in-line SQL

dan!sh 12-Mar-14 8:04

dan!sh

12-Mar-14 8:04

/ = stick
*= his head

Author is literally begging you to hit him with a stick on his head.

Re: A new low in in-line SQL

Jörgen Andersson12-Mar-14 10:51

Jörgen Andersson

12-Mar-14 10:51

Oh, I was Reading it as: / up his *

Wrong is evil and must be defeated.
- Jeff Ello[^]

Re: A new low in in-line SQL

dan!sh 12-Mar-14 17:47

dan!sh

12-Mar-14 17:47

No, that's just evil. Fear the God or broken un-fixable build (whatever scares you).

The Never Executed Loop

Bernhard Hiller12-Mar-14 1:56

Bernhard Hiller

12-Mar-14 1:56

Just discovered that gem:

private string DoSomething(string input)
{
    int len = input.Length;
    //fill up, in case leading 0s were lost
    for (int i = len; i < len; i++)
        input = "0" + input;