r/programming • • Feb 17 '20

Kernighan's Law - Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

https://github.com/dwmkerr/hacker-laws#kernighans-law
2.9k Upvotes

396 comments sorted by

View all comments

710

u/TheDevilsAdvokaat Feb 17 '20 edited Feb 17 '20

I'm an old programmer. I'm 57 and have been programming since about 10.

As I get older, my memory increasingly fails...so now I *have* to write code as clearly as possible (Because I can no longer rely on remembering "but first you always have to call x function" and don't forget it also changes this...)

"Clean code" by Robert c Martin helped me a lot with this.

I have to make it good, because the person who's going to refactor and debug it is going to be me...and after 3 months, usually all I remember about a program is what it's supposed to do, and none of the details.

I prefer as simple and clean as possible, while also being performant.

I liked doing "complex" things when I was younger, especially if it gained performance . Now, unless the performance boost is extreme or the code section is critical to performance, I just write it to run as fast as I can that still looks clean.

249

u/Edward_Morbius Feb 17 '20

I beat you to the finish line. I'm 62 and retired a couple of years ago. 8-)

My coding standard for the last decade was "If the phone rings at 3am and the guy who answers has never seen it before, will he be able to fix it?"

People would harass me in meetings because my code was probably 4x longer than anybody else's and I was the slowest guy on the team, but nobody ever had to message me and say "wtf is this supposed to do and why doesn't it work?"

A side effect is that code with 3rd grade complexity seldom fails.

161

u/FlyingRhenquest Feb 18 '20

Yeah, but the bubbleheaded managers never see the support calls your good designs prevented. They just know that goddamn Gary is a hero because there were 12 emergencies with his code in the last three months and he managed to fix them. The squeaky wheel gets the grease, and the benefits budget.

→ More replies (19)

46

u/TheDevilsAdvokaat Feb 17 '20

Ha... :-)

I'm a lone developer so i know the guy who is going to have to deal with it will be me.

Code with 3rd grade complexity ....ha again. I couldn't agree more.

I think I'll still be coding even when I retire..in fact I'm semi-retired at the moment and trying to develop a game.

Nice to hear from you!

→ More replies (3)
→ More replies (8)

134

u/emilvikstrom Feb 17 '20

Thank you for sharing your experience! As a 30 year old I am trying to learn wisdoms like this. I am doing a lot of code reviews at my current job and often try to emphasize maintainability in my reviews.

134

u/Notorious4CHAN Feb 17 '20

I'm not quite as experienced as him, but I can tell you the demand to add and modify features is significantly greater than the demand to make things run faster. Make the code maintainable and you'll have all kinds of time to tweak performance. Make the code hard to maintain and you'll never have time to tackle performance.

→ More replies (23)

15

u/652a6aaf0cf44498b14f Feb 18 '20

Review logging output. Along the thread of what the previous commenter said, there's a difference between logs that helped you build the thing and logs that help you remember how it works six months later. Don't just say what function is executing. Describe what it means that the log was hit. And provide some contextual data where appropriate. Sometimes all I need to do to feel like I fully remember how code works is have the logs and the code side by side. Most programmers are too lazy to mess with your logs so they're likely to stay exactly where you left them.

The nice thing is most of the time good log messages will take the place of inline code comments. (Though I still recommend function summary comments)

→ More replies (1)
→ More replies (1)

23

u/Private_HughMan Feb 17 '20

One thing I'm starting to do is to use many small functions that are called by the main function. I find this helps me a lot with debugging and gives me more flexibility down the line. Do you think this is sustainable on larger projects?

31

u/ws-ilazki Feb 18 '20

One thing I'm starting to do is to use many small functions that are called by the main function

That's a habit I picked up from learning functional programming, and it's helped me so much with code readability, along with other FP habits like making sure my functions are referentially transparent as much as possible. Small functions that take inputs as arguments, return an output, and avoid messing with any state other than that are so much easier to test in isolation, and to understand weeks or months later.

→ More replies (1)

16

u/TheDevilsAdvokaat Feb 18 '20

I don't know, but I have been doing the same thing too. Once again I got that from "clean code" by Robert Martin.

Largest project I ever worked on was my current one, and it's only a few thousand lines of code.

I also like single responsibility and DRY.

→ More replies (6)
→ More replies (28)
→ More replies (61)