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?
|
|
It's a rephrasing of the old programmer's adage: "don't be clever"! Or Brian Kernighan's famous quote:
Basically it's saying that you shouldn't write clever and/or tricky code because debugging such code later will be very hard. |
|||||||||||||||||||||
|
|
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 |
|||
|
|
|
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:
|
|||||||||
|
|
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):
Today and tomorrow should not be taken literally. You would be a different coder in a few month. |
|||
|
|
|
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. |
|||
|
|
|
The quote, you say, is:
It's not what you seem to have read it as, which would be more like:
…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.) |
|||
|
|
|
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". |
|||||
|
