I don't care how good you are at using the latest debugging tools to step through your program code. Sometimes you want to write to a log or console for execution insight. And if you never do that, try it sometimes. This kind of debugging is best in some situations.
Output all kinds of rich insightful ad-hoc diagnostic information when the mood strikes you. There are no outside rules or limits to what you output. It's only temporary. You are the ruler of this domain.
But be careful.
Don't leave that debugging output statement in the code when you are done with it. Don't be like I was a long time ago, writing temporary output that became lost and forgotten until it was disgustingly rediscovered at the wrong time and place.
Don't be the programmer responsible for obscure debugging messages on the screen during a demo to a client. That is being recorded. Ouch.
Two Pragmatic Rules to Save Your Face and Maybe Your Job
I've applied these two simple rules for almost two decades now in commercial and enterprise software development and spared myself the embarrassment that used to creep on me every now and then.
1. Never, ever, put unprofessional content into your output.
I once created a temporary folder called "killme" as part of a custom installation script for a commercial program that was delivered to 10 thousand users of a client. The folder was intended to exist only as the installer ran. Well, there was a bug. The only bug in the entire delivered product was embarrassing: that temporary folder remained after the installation process completed. Some curious users found a folder called "killme" had been added to their computer. Oops. The name was darkly funny during development for a folder that was supposed to get whacked, but was upsetting when found unexpectedly by users on their computers in the wild. Prompted a bit of explaining to calm people down.
That experience motivated me to assume whatever I output in my programs, no matter how obscure, will be read by anybody and everybody. Keep it professional or at least not shocking.
Easy rule to follow. Requires no effort. Best kind of rule.
2. Have a safe word.
My safe word is LOOK. All my temporary diagnostic outputs have this safe word ALL UPPERCASE as the first thing I see.
Why?
Because before I commit code to a final build I simply do a global search for case-sensitive LOOK. Turns out that word in all uppercase is pretty rare to find in the wild. At least in my programs so far. The only time I find it is if I or a colleague working on the code left something behind that we should remove.
Works nice. I tell all my friends about it.
And there is nothing shocking or upsetting about finding that word unexpectedly.
Before having a safe word, I would find forgotten log and console statements by sheer luck or not at all. I still find some from colleagues that have not adopted a safe word strategy yet.
Summary
Why are you still reading this? There is nothing more to add. Have a good day.
Top comments (0)