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.

First Prev Next

Re: Apparently there is no limit to naming conventions for method

ARopo10-May-12 5:42

ARopo

10-May-12 5:42

I remember some years ago seeing this from one developer

C++

void CommunicationsBlockScheduler::PerformScheduleAndExecuteOfCommunicationBlocksOnAProportialAndPriorityBasis(..)

And another developer on the same team took the oposite approach With gems like this:

C++

void rssr()

This was replicate spread sheet rows

Re: Apparently there is no limit to naming conventions for method

Florin Jurcovici5-Jun-12 23:10

Florin Jurcovici

5-Jun-12 23:10

I feel like laughing my arse off Big Grin | :-D

That's what you do when you:
a) don't know how to use an IDE
b) don't know what OOP stands for

In particular, things like this, among others, were at the origin of OOP creation. Back in the seventies, structured programming hit a wall. Among other things, when your C program grew to 70 KLOCs or so, it seems, you ran out of reasonable identifiers. OOP, providing encapsulation and nice mechanisms to avoid global/public data, got past this issue.

See the writing on the wall...

CDP18022-May-12 22:42

CDP1802

2-May-12 22:42

Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program.

The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here.

And now method #3:

- 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done.

- A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices.

- There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art.

- The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know.

Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:

try
{
    string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
    string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
    MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
    Refresh();
    try
    {
        FileInfo finach = new FileInfo(danapfl);
        if (finach != null)
        {
            finach.Attributes &= ~FileAttributes.ReadOnly;
        }
    }
    catch
    {
    }
    pfl.Attributes &= ~FileAttributes.ReadOnly;
    pfl.CopyTo(danapfl, true);
    pfl.Delete();
}
catch
{
}

This is really an insult to the customer. Good that they will never get to see this mess in all its glory. My recommendation is to quickly write another application and then tar and feather the guy who wrote this one.

At least artificial intelligence already is superior to natural stupidity