Worst source code EVER
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
I think the code written by one of my former colleagues was the worst I ever had to work with (nah, only seeing wasn't enough)... First of all, it was written in Delphi, which means: case-INsensitive - and my colleague definitely used that feature; next, he did not care about formatting anything; sometimes, you had 500 lines without any single empty line (to make the code more readable), but in the next file, you had 10 consecutive empty lines; his naming was OK, but working with the code was still hard, because you never knew what to pass to most functions (for example, passing a "-1" as an ID created a new record in one case, in another function you had to pass a 0 for the same purpose... he never thought about using constants or that alike in such cases); and no, of course there were no comments (which I don't see as problematic - as long as the code is well-written and speaks for itself). When he left our company, I had to take over his project, which was pretty much impossible... the project was soon cancelled.
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
About a third of the way through an 1800-line C function with only a single line of comment:-
l0=l1=l2=l3=0
It took me a while to realise those are lower case L, not figure 1. It took a lot longer to work out what the **** the 1800-line function did... Come to think of it I've seen some pretty nasty Perl now & again too.
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
Now that's easy. It was the program I was hired to replace on my current job. When I first saw it I wanted to publish its complete source code with some annotations at the juiciest parts. There was not one single part in it that I would have kept and the bosses would have liked me to patch it until it works. I told them it was hopeless and in the end I wound up writing an entirely new application. It took me almost a year, but it has been online since last december and, up to now, had only one minor display bug to fix. What was so bad about the old one? Where shall I begin? 1) The database was a mess. The 'developer' did not have the slightest clue what primary keys are for, also had a very shaky grasp of database relations and also allowed nulls in each and every field in each and every table (minus the few keys which were actually defined). The data was imported daily from SAP, so nulls should not occur, but this made it easier for him to sweep errors during the import under the rug. 2) The 'developer' had never heard of object orientation. His 'classes', except for the ASP .Net web pages were all static with static methods, some of those methods thousands of lines of spaghetti code long. 3) Exceptions were only caught at the most buggy locations and always wound up in empty catch blocks. Errors were always swept under the rug. No logging, no message to the user. Stop!here was exactly one location where the catch block was not empty! There an email message like 'An error has occured' was sent to the developer. No information about the parameters entered by the user. No exception message, no stack trace. Just 'An error has occured'. On really bad days I got hundreds of those meaningless messages. This was also the first thing I patched up to get at least some information on what the users were trying to do and what happened then. 4) The 'developer' had never heard about layers or tiers. Everything was freely mixed and mingled over the web pages' code behind or his static methods. 5) There were no separate methods for data access. There was one monstrous method, thousands of lines long, which took about three dozen parameters, then constructed SQL statements in endless spaghetti code and last tried to fill a dataset with rows from all tables. If the user requested too much data, this would result in a out of memory exception on a very well equipped server. Also, he tried to enforce constraints on the tables in the datasets. The very constraints which he failed to enforce in the database itself. Th
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
In over a year at my current job I have not come across a single line of documentation or comments. Thousands upon thousands of lines of code. 20+ projects.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson My comedy.
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
A month or two ago I got to see this Java codebase that I was supposed to work on; whoever wrote it apparently was a fan of this incredibly awesome (NOT!) paradigm I like to call "Hashtable Oriented Programming"... Basically, all business-tier classes implement a BusinessObject interface, which contains four methods: loadFromDb, saveToDb, a third one I can't remember, and the infamous getHashtable... The classes themselves do indeed implement these methods... and nothing else - no bean-style getters or setters! That's right, a Loan object has the exact same structure as a Realtor object; the only difference is the convention of "which keys do we stick in the hashtable?" It's almost as if they were trying to implement some sort of dynamically typed language on top of Java... just with none of the advantages, and all of the disadvantages! Thankfully I've been transferred to another project, so I don't have to mess with that nonsense! edit: Now I remember what the third method was... it was isInDb! This method was implemented rather... erratically, one might say: several of the classes implemented it by executing "select count(*) from theTable" and comparing to zero; if the count was not zero, the object was "in" the database! And no, I doubt that there were all THAT many "singleton tables" in the DB!
-
Now that's easy. It was the program I was hired to replace on my current job. When I first saw it I wanted to publish its complete source code with some annotations at the juiciest parts. There was not one single part in it that I would have kept and the bosses would have liked me to patch it until it works. I told them it was hopeless and in the end I wound up writing an entirely new application. It took me almost a year, but it has been online since last december and, up to now, had only one minor display bug to fix. What was so bad about the old one? Where shall I begin? 1) The database was a mess. The 'developer' did not have the slightest clue what primary keys are for, also had a very shaky grasp of database relations and also allowed nulls in each and every field in each and every table (minus the few keys which were actually defined). The data was imported daily from SAP, so nulls should not occur, but this made it easier for him to sweep errors during the import under the rug. 2) The 'developer' had never heard of object orientation. His 'classes', except for the ASP .Net web pages were all static with static methods, some of those methods thousands of lines of spaghetti code long. 3) Exceptions were only caught at the most buggy locations and always wound up in empty catch blocks. Errors were always swept under the rug. No logging, no message to the user. Stop!here was exactly one location where the catch block was not empty! There an email message like 'An error has occured' was sent to the developer. No information about the parameters entered by the user. No exception message, no stack trace. Just 'An error has occured'. On really bad days I got hundreds of those meaningless messages. This was also the first thing I patched up to get at least some information on what the users were trying to do and what happened then. 4) The 'developer' had never heard about layers or tiers. Everything was freely mixed and mingled over the web pages' code behind or his static methods. 5) There were no separate methods for data access. There was one monstrous method, thousands of lines long, which took about three dozen parameters, then constructed SQL statements in endless spaghetti code and last tried to fill a dataset with rows from all tables. If the user requested too much data, this would result in a out of memory exception on a very well equipped server. Also, he tried to enforce constraints on the tables in the datasets. The very constraints which he failed to enforce in the database itself. Th
I think we are working on the same code. Did you get emailed the code?
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
I think we are working on the same code. Did you get emailed the code?
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
Sounds similar, but our web application was not small at all and also not for internal use only. It was supposed to provide downloads of article and price data for countless markets all over our little country. The old application failed when somebody tried to get more than 15000 articles (plus everything that's attached to each one of them). My last test of the new one was one massive download of all articles in the database ( = 1.5 million). It was one single XML packed into a 16 GB ZIP file :)
"Dark the dark side is. Very dark..." - Yoda ---
"Shut up, Yoda, and just make yourself another toast." - Obi Wan Kenobi -
About a third of the way through an 1800-line C function with only a single line of comment:-
l0=l1=l2=l3=0
It took me a while to realise those are lower case L, not figure 1. It took a lot longer to work out what the **** the 1800-line function did... Come to think of it I've seen some pretty nasty Perl now & again too.
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
The worst was my first engineering job. After two weeks of sitting at my desk learning the hpl language, I was assigned to port a bunch of old test programs for factory checkout of missile guidance systems to a new test bed. The originals were written in GDBASIC, a homebrew BASIC that was not documented other than on closely guarded xeroxed sheets of loose leaf paper, and which could only be obtained by grovelling to the Systems Programming group which wrote the crap. Standard function calls were numbered, not named, and it was necessary to memorize which number would talk to which instrument type and model. Without the documentation it was virtually impossible to determine how many parameters each call required, the data type for each, and in what order they were supposed to be listed. The old code ran on HP21MX-series minicomputers; the new was destined for hosting on HP98-series desktop calculators. The junk I had to port was pure spaghetti code, uncommented, and filled with undefined literal constants that were used in calculations for no discernable reason. I learned later that they were factors like the cable loss in dB from the tester to the missile antenna connector, the magnitude and direction of gravity on the factory test floor where the unit was installed, and other well-known and intuitively obvious values. The hpl language was a breath of fresh air compared to any previous language I'd used, and it was some consolation for the hell of trying to understand what my predecessor was trying to accomplish with his test programs. As a side note, it was on this same job that I committed my first (of many) grand faux pas. When I asked my boss what inept moron wrote this awful code, he looked a bit sheepish, then said quietly, "me, when I was new here..." Oops. :-O
Will Rogers never met me.
-
Now that's easy. It was the program I was hired to replace on my current job. When I first saw it I wanted to publish its complete source code with some annotations at the juiciest parts. There was not one single part in it that I would have kept and the bosses would have liked me to patch it until it works. I told them it was hopeless and in the end I wound up writing an entirely new application. It took me almost a year, but it has been online since last december and, up to now, had only one minor display bug to fix. What was so bad about the old one? Where shall I begin? 1) The database was a mess. The 'developer' did not have the slightest clue what primary keys are for, also had a very shaky grasp of database relations and also allowed nulls in each and every field in each and every table (minus the few keys which were actually defined). The data was imported daily from SAP, so nulls should not occur, but this made it easier for him to sweep errors during the import under the rug. 2) The 'developer' had never heard of object orientation. His 'classes', except for the ASP .Net web pages were all static with static methods, some of those methods thousands of lines of spaghetti code long. 3) Exceptions were only caught at the most buggy locations and always wound up in empty catch blocks. Errors were always swept under the rug. No logging, no message to the user. Stop!here was exactly one location where the catch block was not empty! There an email message like 'An error has occured' was sent to the developer. No information about the parameters entered by the user. No exception message, no stack trace. Just 'An error has occured'. On really bad days I got hundreds of those meaningless messages. This was also the first thing I patched up to get at least some information on what the users were trying to do and what happened then. 4) The 'developer' had never heard about layers or tiers. Everything was freely mixed and mingled over the web pages' code behind or his static methods. 5) There were no separate methods for data access. There was one monstrous method, thousands of lines long, which took about three dozen parameters, then constructed SQL statements in endless spaghetti code and last tried to fill a dataset with rows from all tables. If the user requested too much data, this would result in a out of memory exception on a very well equipped server. Also, he tried to enforce constraints on the tables in the datasets. The very constraints which he failed to enforce in the database itself. Th
"The data was imported daily from SAP" But wait... I thought SAP did everything. Aren't all of those annoying little side-apps with their interface and import requirements supposed to just go away after a successful SAP implementation? And shouldn't costly, difficult-to-manage programmers be a thing of the past? Or was I misled on these points?
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
I did FoxPro for many years. FoxPro is NOT strongly typed and allows public variables. Most experienced developers never use them for obvious reasons. I worked on one very large app that had over a hundred public variables. In some of the modules would be private variables of the same name that simple copied the public value into it:
PUBLIC SomeVar
SomeVar = DATETIME()
.
.
.then later elsewhere
FUNCTION XYX()
PRIVATE someVar
someVar = SomeVar.IF x = 1
someVar = 10
ENDIFENDFUNC
Simple example, but there were hundreds of these public/private combinations all over the app, and you had no idea what was in a variable until you stepped through it or it crashed.
Everything makes sense in someone's mind
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
-
A month or two ago I got to see this Java codebase that I was supposed to work on; whoever wrote it apparently was a fan of this incredibly awesome (NOT!) paradigm I like to call "Hashtable Oriented Programming"... Basically, all business-tier classes implement a BusinessObject interface, which contains four methods: loadFromDb, saveToDb, a third one I can't remember, and the infamous getHashtable... The classes themselves do indeed implement these methods... and nothing else - no bean-style getters or setters! That's right, a Loan object has the exact same structure as a Realtor object; the only difference is the convention of "which keys do we stick in the hashtable?" It's almost as if they were trying to implement some sort of dynamically typed language on top of Java... just with none of the advantages, and all of the disadvantages! Thankfully I've been transferred to another project, so I don't have to mess with that nonsense! edit: Now I remember what the third method was... it was isInDb! This method was implemented rather... erratically, one might say: several of the classes implemented it by executing "select count(*) from theTable" and comparing to zero; if the count was not zero, the object was "in" the database! And no, I doubt that there were all THAT many "singleton tables" in the DB!
ekolis wrote:
It's almost as if they were trying to implement some sort of dynamically typed language on top of Java
Probably exactly that except they didn't know that was what they were doing. They thought they were 'generalizing' it and making it more 'maintainable'. I see designs like that quite often in database layers.
-
In over a year at my current job I have not come across a single line of documentation or comments. Thousands upon thousands of lines of code. 20+ projects.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson My comedy.
When I interviewed for my current job and I was pointedly and specifically asked about documentation I knew what I was in for. Sure enough, none of the apps my predecessor wrote were documented. He was too good to document.
You keep using that word. I do not think it means what you think it means.
-
A month or two ago I got to see this Java codebase that I was supposed to work on; whoever wrote it apparently was a fan of this incredibly awesome (NOT!) paradigm I like to call "Hashtable Oriented Programming"... Basically, all business-tier classes implement a BusinessObject interface, which contains four methods: loadFromDb, saveToDb, a third one I can't remember, and the infamous getHashtable... The classes themselves do indeed implement these methods... and nothing else - no bean-style getters or setters! That's right, a Loan object has the exact same structure as a Realtor object; the only difference is the convention of "which keys do we stick in the hashtable?" It's almost as if they were trying to implement some sort of dynamically typed language on top of Java... just with none of the advantages, and all of the disadvantages! Thankfully I've been transferred to another project, so I don't have to mess with that nonsense! edit: Now I remember what the third method was... it was isInDb! This method was implemented rather... erratically, one might say: several of the classes implemented it by executing "select count(*) from theTable" and comparing to zero; if the count was not zero, the object was "in" the database! And no, I doubt that there were all THAT many "singleton tables" in the DB!
ekolis wrote:
"which keys do we stick in the hashtable?"
Sounds like a fan of Perl.
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
Probably the VB.net I had to work on last year... but there was also the this C code I wrote back in '94...
#define begin {
#define end }
#define then /**/
#define mod %
#define and &&
#define or ||:-O
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
At the least the code written for the Obfustacted Perl Contest was intentionally awful. Here's an example :-
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;printLooks more like a dump of compiled code than source...
-
Okay, last day or so ago, I asked what your favorite programming job was. Now, what is the worst, nastiest, ugliest source code you ever saw and what made it so horribly bad? Not commented (heh heh yeah, as if) or one-letter (or zero-letter?) variable names? Written in a dead programming language that should be dead, but your client is still using it for some God-awful reason? The list goes on...so spew!
Sincerely Yours, Brian Hart
I was hired to port a case management system for intellectual properties (patents, trademarks, etc) to Java/EE. It was written in Power Basic (Sybase 3.5 GL language) by someone who learned programming in C64 basic. I have not seen such clutter before in my life. I found huge blocks of code that literally could've been removed, countless dependencies on global variables, ugly SQL (they often stored their queries in the database - WTF?). Such a mess. I still have nightmares. On several occasions, my design decisions were overridden by their management. One case involved user role management. I proposed the standard role/object/model that is well understood. They agreed, but refused to understand basic set theory. An empty set of access rights would mean "all access to everything" according to them. I responded that is a bad idea, and makes security administration overly complex, and potentially insecure. They would not understand (even after countless of negative use cases). I implemented their stupid ideas. Later on they did not want to pay for my work on the role management, because "it was implemented badly". WTF? They said I did not implement it according to their specifications. Guess what? The "specifications" was my original design! I told them I don't do business with liars, and we went to court. I got half in a settlement. If I had wanted 100% of what they owed, the case would've taken at least one more year. I don't want to spend time in court, I want to create, so I grabbed the 50% and vowed to myself not to fall into that trap again. I was screwed royally on that gig. Code wise and business wise. I have also encountered code for an installer driver that was spaghetti in several dimensions. Structure wise, and thread wise! The code had bugs that the original authors could not track down in 6 months. I spent two weeks with a colleague trying to track it down. I just gave up and kept bugging the management until I was approved to ditch the code, and rewrite it. It turned out that another division in the company had written a really good installer driver, so the story had a good ending!
-- Kein Mitleid Für Die Mehrheit
-
For me, Worst code I see everyday is Catch block with no statements
// ♫ 99 little bugs in the code, // 99 bugs in the code // We fix a bug, compile it again // 101 little bugs in the code ♫
I think they are excellent. They weed out the pros from the wannabes. Just fire the wannabes, and hire new people. Continue until all empty catch blocks are gone!
-- Kein Mitleid Für Die Mehrheit
