|
sometimes the 2nd one. sometimes the latter. every shopping trip is a surprise!
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
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
string output = "value1";
output += "value2";
output += "value2";
...
output += "valueN";
return output;
Another 4 hrs till beer o'clock and I know things will go downhill properly before then.
So what's the worst you've seen done. Or done yourself?
* And yes, the real laziness here is not rewriting the entire WebForms app in MVC. Or Angular. Or Blazor. Or ...
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: 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!
|
|
|
|
|
Chris Maunder wrote: 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.
Excuse me, I now have to return to a webform with two sets of nested repeaters, and a few dynamic tables thrown in for fun! For more fun, let's keep subtotals at every level and page totals using javascript.
"Go forth into the source" - Neal Morse
|
|
|
|
|
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.)
Message Signature
(Click to edit ->)
|
|
|
|
|
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
|
|
|
|
|
Funny you mention, I am currently writing some mighty fine lazy code. Most assuredly will have to refactor everything I am writing...on Monday.
|
|
|
|
|
Kidding Chris, kidding
|
|
|
|
|
Software Zen: delete this;
|
|
|
|
|
the laziest code i see is always my own.
usually if my code was done the right way it's because i'm too lazy to want to have to fix it later.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
bool _IsIndirectlyLeftRecursive(CfgRule rule)
{
return false;
if (_IsLeftRecursive(rule, null))
return false;
if (FillLeftDescendants(rule).Contains(rule.Left))
return true;
return false;
}
It's not even this routine that's broken. This is to short circuit the routine that *calls it* because that fork of the conditional is broken.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Chris Maunder wrote: Laziest code you've seen this week?
The fix for:
[ISC-Bugs #29769]
Inbound packets with UDP checksums of 0xffff now validate correctly rather than being dropped.
Best Wishes,
-David Delaune
|
|
|
|
|
there's just gotta be an exploit in there somewhere.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
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.
|
|
|
|
|
Chris Maunder wrote: And yes, the real laziness here is not rewriting the entire WebForms app in MVC. Or Angular. Or Blazor. Or ...
PHP?
|
|
|
|
|
If no problem with lazy code, but with some people which write big work around with new flags and handling for one special case as my mate proposed on friday afternoon .
I replies on friday afternoon I dont start new coding tasks.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
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.
So:
- 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.
|
|
|
|
|
Chris Maunder wrote: var count = GetCount();
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.
|
|
|
|
|
Here is the laziest code of all:
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?
Sorry for not being funny ...
|
|
|
|