Bug-preventing vs clean code

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.