Maybe you’ve just seen my prior post on killing your darlings while coding and now you think: „Wow, another post? Must have been a rough week!“ Yes it was. A real hacking week. I actually like that, it’s the part of my work I really love, when I get into that coding flow and hack it all down. But there is this point of no return, when you notice that your code has become spaghetti code.

It usually starts slowly and you don’t realize it right away. You were about to extend some of yours or someone else’s code, maybe you don’t have much time left but much more pressure, like I had.

My team colleague was standing next to me and tried to help me out of the hole I dug myself in. It was that point in the afternoon where no coffee could help me anymore and I already drunk my red bull to keep me going. I tried to fix a bug and didn’t bring entity framework to save my related object list. I really couldn’t see a way out of this and wished I could just write a simple sql statement. I’m getting old I guess. A second colleague saw how helpless I was and joined our council. We tried this and that and made it somewhat work and I wanted to work over the code, to make all the dependent parts work again.

I started to use one flag, then a second, suddenly laughed out loudly and told my colleague that you can be sure, that whenever you are starting to use flags, you have finally reached spaghetti code.

Whenever you are starting to use flags, you have finally reached spaghetti code.

I learned at university that flags are evil. Flags are bad, flags are not well designed code. That’s what our professor said. Never use them. Never ever. But are flags really that evil?

I remembered another of my professors at my creative writing education. When I write a text in German (English as well), I usually have a lot of what we call filler words in my texts at first. When I work over my text, I remove them all. I even have a list with my most used filler words, so I can search after them and delete them. Why are they called filler words? Because they can be removed without any replacement.

My creative writing professor was very upset about the fact that filler words have become such a bad reputation. He said, that there are no bad or useless words, but that we just don’t use the words like they should be used. That filler words don’t blow up a text if they are used with caution.

That’s why I started to think about if flags are really that evil or if I’m just usually using them the wrong way. I guess the same principle for filler words can be applied to flags. If you can replace the flag with a nicer piece of code or just delete them, you should do so. A flag is a Boolean after all and Booleans have a right to be used. Or did anyone ever say that Booleans are evil?

Let’s have a look at a small code example:

If we have to check or use isInserted and isUpdated more than once, I guess it would be ok to store the logic in a variable, meaning a flag. Maybe it would be best to do it with a method bool IsInserted() and bool IsUpdated(). If we had a more complex logic for checking if the object should be updated, like comparing lists of objects, we would write a method anyways. At least we can use the middle part of working on the object in both cases like this. But there also might be a nicer way to achieve the same.

Actually a flag or a Boolean is not so different from an enumeration. It also saves a state, but can only save two of them, like on and off. In databases flags can also be used like for example to store if an entry is disabled. In a system where you don’t want to delete items, because you have some sort of historisation and need to be able to go back to an earlier state of the system, this might be useful.

You see I try to somehow restore the reputation of flags. But usually it’s the same with the filler words. They might not be evil, but we use them far too often. Same applies to flags, which most times are a sign of code smell.

Can you think of a place where a flag even should be used?

This is actually something I learned from my creative writing education. Whenever you have a sentence, you think is most beautiful, but doesn’t really fit into the whole text, than you will have to delete it. As a writer this was the hardest lesson to learn for me. I always, always stuck to my darlings and didn’t want to let them go. I wanted to create a happy place for them and what happens was, that I destroyed the rest of the text just to keep them. If you really love them so much, give them a place in your notebook and save them for later. But we all know what later means, yes?, later means never. That’s why it’s best to just kill them. “Killing” because it’s a brutal act for yourself and you might shed some tears. Maybe it helps you to remember, that it was you, who created that wonderful sentence or had that wonderful idea and then get over it.

Why do I talk about this? Because this week – it was a real hacking week with high code output from my part – I realized that this principle also applies to coding.

In our current sprint we had to develop a synchronization of documents. Doesn’t sound all too difficult, though. The web service interface to the other system wasn’t entirely clear and we had to wait for the access users, a query to gather all documents and stuff, so I decided we start with the writing to our database part. I designed a nice separation of concern architecture were we could inject the web service later when we had the saving part up and running as well as unit tested. That worked out pretty well and took more than half of our sprint. When we finally got access to the documents server in our last days of the sprint, we found out that opening a connection to the system was slow and the documents were big. We could have guessed that from the beginning, but at least I didn’t. When I tried to fit the service into our nice architecture, I got horrible performance and memory exceptions.

It was Tuesday afternoon, only 3 days in the sprint to go and I didn’t want to let go of the design and the work we had done so far, so I tried several different ways to still fit the service in. None of them really made me happy. The solutions I came up with killed the separation of concern anyways and weren’t much faster either. I discussed with my team member and told him, it might be best for him to go home, because I might have to redesign the whole thing. It was just then when I remembered the killing your darlings lesson I learned from writing. At 6pm I decided to throw the work of two team members away, as well as all the unit tests and code a whole new approach.

Please don’t misunderstand me, I delete, undo and throw away code all the time. I actually have no big problem with that. My problem was that I had to redesign the whole architecture of the code and throw away the unit tests! Ok, actually I just wanted to keep the unit tests! If I just could have kept the whole interfaces and redesign the black box inside, I could have nicely use my unit tests to see that still all is up and running as expected. And the unit tests took so much time to write! And I did such a nice TDD approach with them. It was really hard to let them go, but they are history now. And with history I don’t mean that there are no unit tests now, I just had to rewrite them too.

I rewrote the code in one day and made it work. Performance is good now and the goal is reached.

The end of the story? If you ever cry about throwing away your code or unit tests, you might just remember me and kill your darlings right away. Maybe it helps you to remember, that it was you, who created that wonderful code or architecture and then get over it.