How to understand "don't code today what you can't debug tomorrow"?

Question

It's a title of a blog. In my option, I absolutely can debug my code tomorrow which I wrote today. So how to understand that?

Answer 1

It's a rephrasing of the old programmer's adage: "don't be clever"! Or Brian Kernighan's famous quote:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?

Basically it's saying that you shouldn't write clever and/or tricky code because debugging such code later will be very hard.

Answer 2

It sounds like the quote means or intends for the developer to write clean and simple code that may be easily understandable even after some period of time .

The code should be easy enough to understand even if viewed after a certain period of time

Answer 3

It's sounds like a play on the phrase "Don't put off until tomorrow what you can do today". It's attributed various people including Benjamin Franklin and Thomas Jefferson.

Essentially it means "don't procrastinate".

If I had to guess, this version is intended to encourage readers to write clean code, particularly if you don't have the time to debug it.

I think that "can't" in this case doesn't mean "if you don't have the ability", it means "if you don't have the time".

So, my interpretation of this title is:

Write clean code today because you may not have time to fix it tomorrow.

Answer 4

Even for simple programs, I remember having hard times understanding some details a few months later. Because I don't not use explicit enough variables, because I did not comment lines that seemed simple back then.

Most often, because I started coding directly, without taking a little time with pencil and paper before to map ideas, to record limitations, to foresee dependencies, to check whether I did a similar program before (which I did forget). Every program, no matter how small and big, is a project, and deserves some project plan, asking at minimum (quoting from the preceding link):

• Why? - What is the problem or value proposition addressed by the project? Why is it being sponsored?
• What? - What is the work that will be performed on the project? What are the major products/deliverables?
• Who? - Who will be involved and what will be their responsibilities within the project? How will they be organized?
• When? - What is the project timeline and when will particularly meaningful points, referred to as milestones, be complete?

Today and tomorrow should not be taken literally. You would be a different coder in a few month.

Answer 5

Since we're in English Language Learners StackExchange and not in Programmers StackExchange, Tomorrow means in the future in its figurative sense (weeks, months, years later), not literal (in 24 hours).

---

If you ever studied your first programming language at school (or at home) several years ago, try to find where you stored your old school projects, and read them. When you wrote them you knew exactly what you were doing right? (don't code today...)

Turns out you will probably struggle to understand your own code, and unless you were an experienced developer when you learned your first language (ahem), you had probably not left many hints for your future self to help him/her understand what you were thinking back then (...what you can't debug tomorrow).

In this sense, when you write code you have to keep in mind someone else is going to read it. And that someone else could be a "future you". The "future you" could go from several days, to several weeks, to months or years later.

Ultimately the saying "don't code today what you can't debug tomorrow" or rephrased "aim to write readable and maintainable code in the long-term" is a general rule for developers. You write code for your colleagues to read, and eventually your future replacement once you'll get promoted or move to work for another employer. Seen from a different angle, if you don't write maintainable code, no-one can replace you and you won't get promoted.

Answer 6

It's a phrase that needs to be understand in terms of maintenance, try to put yourself in to those person shoe who have to deal with the code/project of other person.

What I understand is if you can't understand your after some time then it will be very difficult for someone who is working/solving bug of yours.

So use commenting to your code is very necessary to make it clear, what logic you were having in your mind just note it down, so after some in future if you are working on that same code or someone other then it can be easily have workaround with your project.

Answer 7

The quote, you say, is:

don't code today what you can't debug tomorrow

It's not what you seem to have read it as, which would be more like:

no matter what you code today, you won't be able to debug it tomorrow

…which, as you point out, is nonsense.

The real quote is encouraging you not to write code that is difficult to understand. If you would struggle to understand it if you came back to it in a year, that's bad; if you would struggle to understand it if you came back to it in a month's time, that's a big problem. If you wouldn't be able to understand it enough to debug it tomorrow, then something is terribly wrong and you should not have written it that way. (In that sense, there's some hyperbole in there.)

Answer 8

It simply means write a simple code including comments which can be easily debugged in the absence of the developer who is the owner of the code or may be by the developer itself after a period of time.

Answer 9

When coding, remember some other poor soul may have to debug it, who hasn't been privy to your thought processes. And (as Laurent Duval points out) you probably won't remember either. So write clear comments which inform the reader (especially if the mechanics of what you are doing are at all obscure - e.g. subtle but rarely-used features of the programming language). A bug in the code is forgivable - it can, with some effort, be found and corrected. But a bug in the comments, or in the design documentation, will mislead people for ever. But find the right level. I once had to work on some code which resembled going into a forest where every tree had a label "This is a tree" - when what I wanted to know was "This is 'Kings Wood', producing oak for Naval shipbuilding".