Every day we talk about best practices, efficiency, and optimization. Other than from the depths of r/ProgrammerHumor, and more, we never really talk about bad code. But as I browse Twitter and Reddit I occasionally hear stories of just awful code. The snippets the still gives you nightmares because you know deep down you know it's still out there running in prod.
So in a moment of gaining perspective for all sides of software development, and jest, what are your stories?
Top comments (9)
Something akin to this still exists in some code bases I have to work on.
Step 1:
SELECT
many rows from the databaseStep 2: Loop thru each row
Step 3: *
SELECT
each row again for some data not fetched originallyStep 4: *
SELECT
rows from a child tableStep 5: * * Loop thru each child row
Step 6: * * * Keep only a single row and ignore the rest
Step 7: Never use any of the data
I saw something similar in the last legacy app I worked on. Bear in mind this was a single, monolithic, method embedded in a Windows form. It went like this....
Step 1:
Do For Each User Criteria Entry
Select a lot of rows from the database using unparameterized user entry
Loop through the results to load them in an array
Loop through this array doing a switch to determine which single row SQL to execute, loading the resulting data into a new array.
Clear out the original array.
Loop
Step 2:
Loop through the results array, adding/deleting values based on poorly documented business rules and deleting any duplicates.
Step 3:
Repeat of Step 1, using slightly different criteria on the switch SQL statements based on the business rule modifications. It was likely this code was cut and pasted from step 1 and modified.
Step 4:
Loop trough the results array again to delete any duplicates
Step 5:
Display the first record from the array (there was only supposed to be one record by this point but that didn't always happen)
The worst I've seen is legacy code from internal corporate applications that was written over a long period of time (10+ years) by either unskilled developers or multiple developers/contractors at different times. There is serious "code rot" throughout the code base. Testing outside of the full production environment is virtually impossible. If you took the principles of SOLID and DRY and reversed them, you would have this kind of code.
One common example I used to see a lot in the VB6 days and that's still around sometimes today is running an application on users' systems in the IDE rather than compiled. Why? Because the application won't work correctly compiled to an EXE! Often this is due to a dependency problem that couldn't be resolved by the developers.
There was a cut-and-paste masterpiece I had the misfortune to work with where the original developer bragged about it having a million lines of code. It probably did although well over half of it was the same code with minor modifications. Database access was scattered all over the place so it was difficult to know exactly which function was going to be called when. Any modification anywhere in the code was very likely to cause serious problems elsewhere. It was the definition of brittle code.
My old jQuery code when trying to code a mini slider. All it consisted of is 8 strings fading in and fading out one after the other. For the most part this is fairly easy because of jQuery's callback function. Also this is what made it horrible... jQuery's callback function. Picture this code as my jquery function...
It was a manual SOAP implementation for a web service. It had about 5 or 6 levels of nested function calls, each caller wrapping the XML returned by the callee within some other XML tags - the outer functions with SOAP stuff, the inner ones with the structure of the web service's response.
The wrapping was done like so:
I saw it when we were investigating OOM crashes ("how could it be? C# has a GC!") in a production(!!!) server that was serving large requests (hundreds of MB each) and the profiler suggested there were too many huge
String
objects. That server was running the previous version of the web service, which was only doing that wrapping trick once - so we considered trying moving it to the newer version but then I saw that abomination...I have seen a table design where developers instead of using data types they have saved all their values as nvarchar and delcared a column where they have specified in a text fashion the data type ( sql server built in data types were insufficient)
i am currently writing my worst ever piece of code
maybe because i am new to FRP
This isn't the worst one but I remember this :
And that was ..