The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I have deadlines and I have code to write, and that means I'm constantly doing the devil vs angel "but no one will notice" conversation with code. Maybe I do var count = GetCount(); which seems fine except it's lazy and GetCount() actually returns a long not an int and so the next person comes along wanting to punch you because they have to do a cast.
Or instead of using a repeater in a WebForms app* I just inline the logic directly into the ASPX page. Or I do
So what's the worst you've seen done. Or done yourself?
Writing self-modifying Z80 assembler code to process caps lock on a VDT?
Yes, that was me ... in my defence it was a long time ago and the VDT's are almost certainly crumbled to dust by now. Anyone seen a Lynwood Alpha or Beta? Or even heard of 'em?
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
So what's the worst you've seen done. Or done yourself?
Probably coding a specific logic for a specific customer 'cause it's a one-off or I don't have time to do a proper option.
I had to get something working for a test and demo two weeks ago.
I was running out of time so I hard-coded an ID and a secret into the application to connect to some services
In my defense, it'll never see production (I'm not even sure if I believe that myself )
I have been bitten by that a few times. Eventually I resorted to adding little booby traps that would prevent things from being deployed as a self-defense mechanism. The first time they discovered one I told them I did that so you wouldn't do what you just did - try to use it in production. They didn't like it when I asked them, "what part of not ready for production do you not understand?" in front of three levels of bosses.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
I've done something like that once.
It required some dubious unit tests, but they did what they should on the build server
Everyone on the team was quite happy with them, because we did actually check in some test code a few times.
those, and sometimes in SQL statements concatenating user input string/varchar values
but only pre-release / personal test - never in release
(probably a bit anal about it but I'll purposely work longer to fix these things before knocking off for the day/night ...SQL parameters, clean up strings / use stringbuilder, replace every single var with the proper type.)
A quick and dirty 'CleanupTool' I wrote in C# for use on our builder, it accepts up to three command line parameters, the start path, the directory to delete (bin), and a range of exclusions.
It works with the directories we have, but don't have any expectations beyond that
This is from about a week ago. I wrote a routine that captures the user comments about certain states of a map (like, an actual map of a city). This routine is then supposed to store it to be read by another piece of code that generates reports.
Out of my superior wisdom, I elected that the path to the map images captured, the associated comments, etc. should be stored as a CSV file (don't ask - it was 5.40PM). I spent the next morning trying to figure out why the report generation was tripping up. Of course, the user could enter commas in their comments (the strings aren't quoted) and that did horrible things to the naive CSV parser.
I have since cleaned up traces of my idiocy and all data now properly goes into a database table from where it gets read.
The worst I've done was low-level parsing in the high-level part of my parser. The low-level part I inherited is, understandably, somewhat complex and I was running low on time so I've made a low-level distinction between two values in the high-level part framed with a comment about how sorry I am.
I wrote a C++ program to close a dialog which is left open by another program when it loses it's connectionto SQL Server, which it does on a not infrequent basis.
In my defence:
1. The offending program is written in VB6 and I am not refactoring that.
2. It is running on Windows 7. Not an actual server OS. (Until last year when the physical hardware got vitualised it was XP)
3. No one else here really knows C++ so that will be my lasting gift to them
if (claim.Contract.ProgramID == 280)
taxAddOns = ClaimsAccess.AddTaxToAddOnList(taxAddOns, claim.Contract.ProductID);
and then the ClaimsAccess method hard-codes building the objects it returns, instead of looking at the database for them.
- Too lazy to add an attribute to the Program data to represent the business need
-- Probably really means they didn't understand the business need
-- Of course, nobody else will ever want this to happen, so we shouldn't even make the program id a configuration value.
- hard-coding the construction of the objects instead of running off to the database
This is the sort of terrible approach I have to fight every day, day in and day out.
Using var is possibly the laziest code technique I've ever run across. It makes the code harder to read and opens up the real possibility of type cast errors when the initialization results in the wrong data type.
The code which is written correctly FIRST TIME around, with no correction needed to it ever, no need to revisit it ever again.
Does it have to take longer?
No, because you'll never spend time on it again.
Does it take a long time to write such code?
Not if you actually are capable of perceiving all ramifications of it, and actually confront the entirety of the issue at hand.
The writers who spend 7 years to write a 500 page book don't actually write better books ... did you know that most of the well known artists like Mozart etc, spent incredibly little time to create immortal master pieces?
did you know that most of the well known artists like Mozart etc, spent incredibly little time to create immortal master pieces?
My understanding is that this is actually an urban myth (Here's a Guardian article[^] that mentions this too)
If you can write code that works first time, no fixes, forever and ever then I take my hat off to you. You've either put in a lot of work to get to this point or you're incredibly lucky. It's usually the former.
What I was after wasn't the code that took the least effort to write. I was after the code you wrote with the least *thinking* and that you know, deep down, is just wrong, but you do it anyway. Like eating a doughnut: so wrong, but so easy.
Last Visit: 22-Oct-19 12:04 Last Update: 22-Oct-19 12:04