![]()
Insanity: doing the same thing over and over again and expecting different results.
Albert Einstein
You obviously never done any multi threading work, dude!
Originally posted at 3/30/2011
I have seen all of those in production code…
-
throw new NullReferenceException();
-
public class AbstractController : Controller // or // public class AbstractPag : Page { public static bool IsAdmin { get;set; } }
-
public static class BlogMgr { public static void AddPostToBlog(Blog blog, Post post) { blog.Posts.Add(post); post.Blog = blog; } }
* I could only think of three, but I didn’t want to modify the title. Can you complete the list?
Originally posted at 3/8/2011
I use a sort of a ranking sheet when I am doing code reviews. I recently run into one that was really horrible…
Fairy tales always start with “Once upon a time”, and programmers tales starts with “when I was at a client”…
Two days ago I was a client, and the discussion turned to bad code bases, as it often does. One story that I had hard time understanding was the Super If.
Basically, it looked like this:
I had a hard time accepting that someone could write an if condition that long. I kept assuming that they meant that the if statements were 50 lines long, but that wasn’t the case.
And then yesterday I had an even more horrifying story. A WCF service making a call to the database always timed out on the first request, but worked afterward. What would be your first suspicion? Mine was that it took time to establish the database connection, and that after the first call the connection resided in the connection pool.
They laughed at my naivety, for it wasn’t connecting to the database that caused the timeout, it was JITting the method that the WCF service ended up calling.
Yep, you got that right, JITting a single method (because the runtime only JIT a single method at a time). I had even harder time believing that, until they explained to me how that method was built:
Some interesting stats:
- It had a Cyclomatic Complexity of either 4,000 or 8,000, the client couldn’t remember.
- The entire Rhino Mocks codebase fits in 13,000 LOC, so this single method could contain it several times over.
But you know what the really scary part is?
I upgraded from Super If to Black Hole Methods, and I am afraid to see what happen today, because if I get something that top the Black Hole Method, I may have to hand back my keyboard and go raise olives.
Following up on my previous post, the customer has complained about table names like [tbl_-1434067361], apparently they felt that this was misusing their naming policy. I told them that while I understood that, it did meet their naming policy. I got a new naming policy that stated that numbers are not allowed in column or table name, (and showing forethought) that table names must be composed of valid English words.
I, of course, decided that if this is what they wanted, they will get just that. And created this:
The words.txt file was taken from this URL: http://www.puzzlers.org/pub/wordlists/pocket.txt
The result is exactly per their specification:
create table [tbl_colonel] ( [col_verbiage] INT IDENTITY NOT NULL, [col_unsparing] NVARCHAR(255) null, [col_indomitable] NVARCHAR(255) null, [col_bulldog] BIT null, [col_thank] DATETIME null, primary key ([col_verbiage]) ) create table [tbl_stump] ( [col_upheaval] INT IDENTITY NOT NULL, [col_promissory] NVARCHAR(255) null, [col_predecessor] NVARCHAR(255) null, [col_chafer] NVARCHAR(255) null, [col_unyoke] INT null, [col_vise] NVARCHAR(255) null, PostId INT null, primary key ([col_upheaval]) ) create table [tbl_reprieve] ( [col_wherewith] INT IDENTITY NOT NULL, [col_wolf] VARBINARY(8000) null, [col_legendary] NVARCHAR(255) null, [col_ago] NVARCHAR(255) null, [col_carabineer] DATETIME null, [col_referee] NVARCHAR(255) null, primary key ([col_wherewith]) )
The fun part about this approach is that you still get great level of security, while maintaining the naming convention. Even more than that, you get queries like:
SELECT col_verbiage, col_indomitable, col_bulldog, col_wolf, col_legendary, col_referee FROM tbl_colonel JOIN tbl_repreieve ON tbl_repreieve.tbl_referee = tbl_colonel.col.unsparing WHERE col_ago = 'Fun@house.at'
It is obvious that we are getting users & blogs with specific email, right?
This is actually much harder than just numeric values, because this is going to really mess with your mind.
Nitpicker corner: Yes, this is a humorous post, don’t take it seriously, and please don’t really do it to unsuspecting customers / DBAs. Unleash it on silly integration teams only.
I'll be the first to admit that I am not the best at Geography, but somehow I don't think that this is likely.

Those are just things that I happened to hear or say in the last week:
Q: Did you read the book Beautiful Architecture?
A: No, I don’t read fantasy books.
And:
Q: Why are you doing the dishes?
A: I was a C++ programmer for a long time, I am used to cleaning up after myself.
