If I'm faced with the decision to write clean, beautiful code, but I'd be opening up a new path bugs could take to appear, should I take it? (Provided I'm not willing to spend the time to come up with a way that satisfies both.)

To elaborate: I'm writing a Pong game as practice, and I could either write the exactly same line of code in two if-else statements or include it as an else statement. The latter approach is certainly more elegant, but it means that any unaccounted for game objects will trigger it. They shouldn't.

Now, since this is a Pong game, the only game objects are the two rackets (or whatever they're called), the ball, and visible walls the ball can either bounce off (i.e. the horizontal ones) or invisible walls that serve as triggers for it to cross to score a point (i.e. vertical walls). So, the addition of an else statement shouldn't be catastrophic in this case.

But what about in other, similar cases I'd encounter in the future, working on other projects? Should I neglect writing clean code in favor of practicality or not? Or should I perhaps include an error case that would print to the console in case it's set off, to clue me in and make debugging easier? Or should I really just take the time to write code that is both clean and bug-preventing?

I want answers from the perspective of both a solo developer and one working in a team. It doesn't have to be about game development, but rather programming in general.

What's the better practice?

  • 5
    It isn't clean code vs bug prevention when the "clean code" isn't actually correct in the first place. Ideally, the cleaner version of any code has the exact same behavior of the original code, without introducing new bugs.
    – T. Sar
    Commented Jun 6, 2018 at 17:07
  • Also - Use a switch with an enum, if your language permits.
    – T. Sar
    Commented Jun 6, 2018 at 17:08
  • It is correct. However, there's a slightly higher chance of bugs with it. Hence "opening up a new path" vs "creating a bug". Commented Jun 6, 2018 at 17:10
  • 5
    To be straigth, if you are not willing to come up with a way that satisfies both in a reasonable amount of time, you should better change your profession, this will be better for the world. If you are not able to, but willing, that's fine: discuss your real code with others, learn from them how clean and correct code looks like.
    – Doc Brown
    Commented Jun 6, 2018 at 18:29
  • @DemetreSaghliani If there is a different behavior arising from the Clean Code from the Spagetthi one, it is absolutely not correct. What you're calling "clean code" isn't clean in the first place - you should be using a switch with enums, and not some series of ifs.
    – T. Sar
    Commented Jun 6, 2018 at 18:35

3 Answers 3


Clean Code vs. Bug-Free Code is a false dichotomy. If you introduce a bug in an attempt to make it "cleaner" (or make it more brittle by "opening up a new path" for bugs) then it is not really cleaner, it's just different (and arguably worse).

"Elegance" is a matter of taste. Some people like lambda expressions; it is their latest golden hammer that makes everything look like a nail. But lambda expressions are just like everything else; they have a "sweet spot" for their use.

Saving a couple of lines of code while risking new bugs is not an effective tradeoff. Instead of thinking in terms of mere elegance, try thinking "more robust."

Any refactoring should be preceded by a suite of unit tests that will "prove" that your code still works after being refactored.

  • Even if the risk is really low? I said I'm writing Pong because there are few variables (actual, not code) to account for. Still, I'm learning the program, so for all I know, Unity could screw me over, here, if there are some quirks with the engine I'm not aware of. More, if I decide to add any new features to the game (though that's pretty unlikely; this is just a weekly practice project), this might cause a bug. Either way, thanks for the answer! Commented Jun 6, 2018 at 17:18
  • 6
    You're overthinking this, of course. Correct code (in the sense that it has the reliable, predictable behavior that you want) trumps almost all other considerations. That is the primary reason you write code, after all. Commented Jun 6, 2018 at 17:20
  • 1
    Although elegance is a matter of taste, in most technical fields, elegance refers to simplicity. In the art world, it may refer to a baroque design, but I do hope we are not heading in this direction in the software industry. Commented Jun 8, 2018 at 22:37

It depends on the nature of the application you are developing and also on some other parameters i.e. deadline of the project, team vs soloness, maintainability and extendability.

Let me give you an analogy, you are supposed to make an airplane ATC software where a simple bug can break communication system and lead a very bad consequences. On the other hand if you want to build an application to stream from video and a bug can miss some of the frames the consequences are not that bad.

Finally, always remember a clean code is supposed to be clean because of not its appearance its because of its nature of easy bug prevention and identification. I personally have biasness towards clean coding.


Let me take your question to extreme by using an analogy.

Should you care for clean operating room or the one where instruments works right? You can sprinkle chlorine all over, take our all those ugly catheters and wires away: The operating room will be quite clean, but faulty instruments will make both surgeon and patient unhappy.

I'd taken it to another perspective. Clean code belongs to the form of the code while bug-free behavior is directly related to the solution of the problem.

As Clean Architecture: A Craftsman's Guide to Software Structure and Design, First Edition by Robert C. Martin says (note, he also equates design and architecture):

"The goal of software architecture is to minimize the human resources required to build and maintain the required system."

I can only add, that it's almost impossible to foresee with 100% accuracy how the system will be developed with time, what new cases will be prevalent. But if the architecture is well-thought, developers understand the domain, then system's evolution will be smooth providing for both clean architecture, code and minimizing bugs. Of course, practicality is in the balance of the predicting expected system development directions (long-term) and acute business needs (short-term).

I guess, the answer is: care about architecture and both goodies you are trying to counterpose.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.