Break the rules! (but only if you understand them)

There are a lot of ‘rules’ in software engineering. Don’t copy-paste your code, don’t use goto, your code should be easily understandable, and many more. Generally these rules make sense, but every once in a while someone will have a hot take, and post about how you should copy-paste your code everywhere, how goto is the greatest invetion ever, or how variable names should be shorter.

I’d like to advocate for a middle ground, and say that ‘it depends’ (which is true for almost anything in software). While most of the time you shouldn’t copy-paste your code, there are cases where it makes sense. And while goto is generally a bad idea, the symfony code bases uses it.

When can you break the rules

Personally I try to only break a rule if the following are all true:

I understand why this rule is in place

With the example of copy-pasting code, I’d like to think at this point I understand why this rule is in place. If you copy-paste code all over your code base, you reduce maintainability. You make it harder to make a change, instead of having to update it one place, you have to update your code at every place you copy-pasted it to.

There is an actual benefit to breaking this rule

Often people will break a rule, just because it easy at that moment. Copy-pasting your code is easier than making a good abstraction to re-use. But sometimes there are benefits. For example, sometimes you want to copy-paste your code if there is not ‘right’ abstraction. If 2 pieces of code to the same thing, but that by coincidence, then an abstraction doesn’t make sense.

The benefits outweigh the downsides

Even if there is a benefit to breaking the rule, it has to outweigh the negatives. And this really depends on the goals for your code base. For example if you’re writing a piece if code that gets executed a million times per request, then, the performance of that piece of code may be more important than the readability. But it comes down to what is more important for that piece of code.

Closing thoughts

A lof of the times I’ll decide not to break a rule at because there isn’t an actual benefit (besides it just being easy), or because while there is a benefit, it doesn’t outweigh the downsides. The first check is mostly there to check if I actually know what I’m doing. Especially if I’m doing something new, like trying another language, or working in a new paradigm, then understanding the rule comes into play. If you’re just starting out with something, try to stick to the rules, until you understand the up and downsides of that rule.

What rules do you break sometimes, and how do you determine which rules to break? Let me know in the comments!

If you want to get notified of my next blog post, join the newsletter