Code Hoarding

Life as a software developer is probably not what most people think it is, many imagine coders as we are portrayed in films or series; sun-shy nerds sitting in darkened rooms hammering away at keyboards in a code trance creating the software that will change the world! Yeah not really, in fact being able to create projects and software from scratch, is something of a rarity, for example recruiters often throw around the term “Greenfield Project” in job adverts to garner more interest in their roles.

I would say being a dev is more a hybrid of working at a nursing home and being an archaeologist.

A new product, once out of its embryonic state, will start out hale and healthy like an Olympic athlete but as the years roll on, there will be added requirements, edge cases and general bumps and bruises and the underlying technologies change as the world moves on. Before you know it the product has reached a state of senescence, with some surviving the ravages of the years better than others. For many of us, keeping these old geezers alive is a full time occupation.

That’s where the archaeology part comes in. The chances are, you weren’t around when your product was created and your job involves scouring the code base and understanding how things work, in order to fix and maintain them. It’s not quite Indiana Jones territory, more like dusting through layers of sediment to really grok the architecture and data structures. If you go in there with a hammer you’re likely to destroy things before you’ve even had a chance to understand what you’re doing.

One of my colleagues has recently been given one of these monumental tasks, a piece of software that lies at the critical intersection of just about every product we currently have, and to make matters worse, it’s on life support and has been for a number of years. So needless to say, he’s moving very cautiously. I was chatting with him about this recently and he commented:

“I knew the code base was bad, but I had no idea that <original dev> was a Code Hoarder as well!”.

I’d never heard this phrase before, but instantly recognised what he was talking about without need for explanation. A Code Hoarder is someone who cannot bring themselves to throw code away, instead they will either comment out huge blocks of code or worse, just bypass the obsolete code without ever removing it.

You can imagine the complications this causes another developer, when already facing the daunting task of getting their head around 100,000s lines of code, their life is further complicated by the fact that it’s littered with these unintentional booby traps.

I’m incredibly passionate about this and think that this mindset is one of the skills that shows the difference between experienced developers and more junior ones and that’s not just developing something to the point where it “works”, but considering the future maintenance of the code. If there are 50 lines of code REMed out in the middle of a function, I have to stop and consider why? What purpose is there to leave this behind? Why didn’t they just delete it? Whatever the answers are, they’re sure to get lost in the mists of time. I mean, we’re all using source control right?

So next time you’re about to comment out a huge swathe of your code, or render a function unused, ask yourself “Shouldn’t I just delete this instead?”.

Don’t be a Code Hoarder.

Validating Classes using Data Annotations

We’ve been beefing up our validation routines recently as it became clear that we needed to add a lot more protection to our Validation Engines in our NetCore project.

We use EFCore Code-First to generate our database in which we have a large number of Data Annotations such as:

    public string Surname { get; set; }

Our testers have started really getting into min/max testing so they’ve been happily trying to put oversized data into all of our fields, and guess what? We’re seeing Internal Server Errors all over the place.

So we’ve been faced with a challenge about where to implement our validation and how and even what level. Whilst investigating solutions, I realized that we can re-use the same Data Annotations on our EF Entities as part of our validation routines, which means that in addition to our more complicated business logic, we can check for things such as Surname being less than 50 characters, all using generics.

Below is a sample function which will work with any class marked up with Data Annotations and add them to a custom class we use for catching and reporting validation errors. The key points to note here are the ValidationContext and TryValidateObject().

            var modelValidator = new ValidationContext(toValidate);
            var modelFailures = new List<ValidationResult>();
            if (!Validator.TryValidateObject(toValidate, modelValidator, modelFailures, validateAllProperties: true))
                foreach (var failure in modelFailures)
                    foreach (var memberName in failure.MemberNames)
                        result.ValidationErrors.Add(memberName, failure.ErrorMessage);

We then convert the ValidationErrors class into a ModelState so that we can return a 400 error.

Optional One to One Relationships in EFCore

My company is currently working on replacing our venerable WinForms application with a shinier ASP.Net MVC version and rather than just re-write everything as a slavish “lift and shift” approach, we’ve gone for the bolder approach of completely re-designing the whole thing from top to bottom. Cue buzzwords such as “Greenfield” and “Blue-sky thinking” etc etc.

As part of this, we made an early decision to move to an Entity Framework Code First approach and try to keep as close to the cutting edge of technology as possible, so whilst we started with EF Core 3.1, we’re currently on EF Core 5. As someone who has been mucking about with SQL Databases since the 90s, it’s hard to let go of the SQL and just let EF manage and control everything, but once you embrace the mindset and just let it go, the benefits have been substantial.

However, one thing that has been niggling at me is managing 1:1 relationships and especially optional ones. It wasn’t long before we designed our first 1:1 relationships and instantly hit some problems.

Let’s look at the below diagram. Here we have Requirements which have an optional 1:1 (aka zero or one) relationship with a set of Features. When a Product is created from these requirements, it will also have a set of Features, nothing complicated here, all we’re doing is putting the set of common fields in a separate table, if we happen to have them.

Sample ER Diagram

So the first thing we did here was try to add a simple navigation property to Requirements, Products and Features and hoped EFCore could work this out by magic; something like:

public virtual FeatureEntity Features { get; set; }

Your migration will generate fine but as soon as you try to apply it and code against it, you’ll see this fun error:

The dependent side could not be determined for the one-to-one relationship between ….

Which makes perfect sense if you think about it, how on earth should we expect EF to work this out? Don’t get me wrong here, EF is about as close to computer witchcraft as I’ve seen in a long time, but you’ve got to give it a helping hand in places. Unfortunately this error leads you down the path of trying to use the fluent API to try and configure the relationship by hand, but I very much disagree here, the fluent API should only be used when you can’t express what you’re trying to achieve via Data Annotations.

What we actually want to do here is configure the foreign key properties in the dependant table. So in our FeatureEntity we add our navigation properties to Requirement and Product but we additionally add RequirementId and ProductId.

Because I’m following a naming convention of {TableName}Id, EF can work everything else out itself. No need for a ForreignKey data annotation.

public class FeatureEntity
    public Guid Id { get; set; }

    public Guid? RequirementId { get; set; }
    public Guid? ProductId { get; set; }

    public virtual RequirementEntity Requirement { get; set; }
    public virtual ProductEntity Product { get; set; }


After this all you have to do is add your Navigation properties to Requirement and Product (nothing extra required here) and EF will magic together the rest for you.

The final point of note here is the optionality of the relationship. As you can see above, I’ve declared that both of these FKs are optional by using ? after the type. It’s as simple as that.

If you review your migration and ContextModelSnapshot, you’ll see that the FKs will all be unique and indexed and EF has worked out the details for you using the HasOne()/WithOne()/HasForeignKey() structure for you.

No custom OnModelCreating, No Fluent API. Simples.

Hello World

“Hello World!”, you’ll often see this chirpy piece of text in relation to computer programming and I think it’s highly appropriate that my first post on this blog is in keeping with that tradition, but where does this come from?

Before I started to write this post I thought I knew the answer with a laser-like certainty, but as is usually the case in these situations, when we’re at our most certain, we’re also at our most mistaken. Though the exact origins of Hello World remain lost in the mists of time, its use as a test phrase is widely believed to have begun with Brian Kernigham’s 1972 book, A Tutorial Introduction to the Language B. In which, the first known version of the program was used to illustrate external variables.

But I, as many of you was introduced to this expression back when I, albeit unknowingly, started on my journey to becoming a software developer. I can’t remember the exact year but I was definitely under the age of 10 when my mother suggested I might want a computer as my Christmas present. I wasn’t sure about this and I suspect I was persuaded into the idea. I’ll have to check with my mum here to get the facts, but this is how I remember it.

Roll on Christmas day, and I was confronted with my very first computer, a Sinclair ZX Spectrum as shown in all of it’s glory above. This was the very cutting edge of what would become Personal Computers and I won’t bore you with the history or details, beyond knowing that in order to even do anything with a Spectrum, you had to start typing code. Yup that’s right, if you ever owned a Spectrum, an Amstrad, Commodore or BBC Micro, you were basically being groomed into a career as a software developer without even knowing it.

Start screen of the ZX Spectrum
Touch any key and you’re instantly transported to a command line
Within minutes you’re writing your first program

I imagine that confronted with such a thing, you would be turning straight to the manual, and this is where the magic starts. After some extensive blurb about connecting up the myriad of wires, the first thing your manual tells you to do is get your new friend to say “Hello”.

Again, I’m surprised here, I would have bet a large portion of my fortune that the first thing I typed was “Hello World”, but having dutifully tracked down the very same manual on the internet, it turns out the first program I ever wrote was not “Hello World”, but in actual fact it was “Hello”.

The rest as they say is history: you quickly learned how to Load/Run games from cassette and that’s where most left it. Yet the more inquisitive in our midst would have absorbed that manual and been writing their own programs in short order and that is essentially the story of how I wrote my first program and set my feet upon the path of becoming a software developer.

These days, “Hello World” (See? I do get back to the point eventually) is used as the standard first piece of code written in computer languages, in fact there was a strong trend for a language to be judged on how simple it was to send this innocent and chirpy piece of text to the screen. Funnily enough, there are very few languages that can match the BASIC of the 80s for simplicity of this code.

I’ll leave you with what was probably my second program: