5 ms·
Both fail for me. There's a middle ground I aspire to. All I want from code is clarity. Not just for me, but for anyone who has to touch the code in the future
by buro9 15y ago
Both fail for me.
There's a middle ground I aspire to. All I want from code is clarity. Not just for me, but for anyone who has to touch the code in the future.
The first is so verbose in comments that you don't see the little code there is. And you couldn't see all the necessary code on the screen.
The second (now) is so dense that you have to read the code carefully and slowly to understand what it's doing.
I have the luxury of time when writing code, I can consider it and lay it out however I want, comment it how I want. To a person fighting a critical bug they lack this luxury. It's my job when I create code to help the person debugging it (even if it's me) to understand the code as quick as possible so that they may find and solve the problem as soon as possible.
Three things I always remember when I code and design software:
1) Debugging is harder than writing code, so if you've been clever in writing code you are by definition not clever enough to debug it.
2) UNIX philosophy... do one thing well.
3) Write both the code and comments in a Hemingway style. Use no obscure language, keep it in layman's terms... but say only what you need to say.
- sbuk 15y agoFurther to your 3rd point, you can go further and apply Orwell's 6 rules of writing from his essay "Politics and the English Language". The last rule is the most important. 1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print. 2. Never use a long word where a short one will do. 3. If it is possible to cut a word out, always cut it out. 4. Never use the passive where you can use the active. 5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent. 6. Break any of these rules sooner than say anything outright barbarous.
- hn_reader 15y ago> "To a person fighting a critical bug they lack this luxury. It's my job when I create code to help the person debugging it (even if it's me) to understand the code as quick as possible so that they may find and solve the problem as soon as possible." I am quite often in this situation - maintaining code written by others on a very tight schedule, weekends, evenings, trying to find and fix bugs and still make it to the next family commitment, etc. Wish more people understood this and considered the many future maintainers when writing their code.
- jodrellblank 15y ago1) Debugging is harder than writing code, so if you've been clever in writing code you are by definition not clever enough to debug it. Citation needed. And I don't mean proof by appeal to authority because someone famous once said it. Debugging is different to writing code - you can spend longer thinking about it, you can bring different tools to bear on it, you can focus your attention on smaller or larger pieces of the problem, you can stop thinking about any of the surrounding context which is irrelevant to debugging, instead of having to think about the context relevant for programming. Is it measurably harder, or is it a less used and less practised skill so not learned as fluently? Is it that programming is seen as "default-success-unless-proved-broken" and debugging is seen as "a-failure-until-fixed", so there's a psychologically different feeling in approaching one than the other? Is it that programming usually happens earlier in a project and debugging later, so there's more stress and deadlines looming? Is it that debugging happens when a problem has been found and now you are acutely aware of what's being held up until the debugging is done? This quote suggests there is code out there which has known bugs and the authors have tried hard to find them, with enough examples to work from, and never succeeded due specifically to limits of their cleverness. Is this anecdotally true for anyone here?
- deleted 15y ago[deleted]
- andrewflnr 15y agoI don't know about the "not clever enough by definition" part, but I agree that debugging is harder than writing new code. If you're debugging your own code, you're trying to find something out about it that you didn't understand when you wrote it. You're looking for one of an almost infinite variety of side effects or subtle misunderstandings of interfaces, and you have to find which one it is. There are usually more ways to go wrong than right. You then have to change your brain to add this understanding, which is difficult, while writing code is likely to take advantage of existing mental structures. When you're debugging someone else's code, you have all the same problems, except you don't have the benefit of knowing what the writer was thinking at the time, that initial understanding. So yes, you have more time to do it, but that's because it takes longer, and it's more a wrack-your-brains time than writing code.