3 ms·
I almost caused a version of our product to be shipped with a 'Blah' hyperlink on the About window. I was testing a new style of button, and the About window wa
by PlunderBunny 2y ago
I almost caused a version of our product to be shipped with a 'Blah' hyperlink on the About window. I was testing a new style of button, and the About window was just a convenient place to put it. This was a long time ago, prior to our adoption of source-control in the company, so I made the builds directly off my laptop.
There were many lessons I _should_ have learned, but what I chose to do was to surround all my testing code with #ifdef _DEBUG to make sure it didn't get out to real customers.
- miki123211 2y agoThis is why I think it's a good idea for languages to have two print functions, one of them specifically intended for temporary debugging, the other for cases where you genuinely want to print to the console, e.g. in some utility script. This way, you can have a linting rule that prevents any "debug prints" from being committed to your repository. Go kind of works that way, there are the "official" printing functions in fmt, and there's also a pretty much unused builtin println which works well enough for this use case. I find that it's also a good idea to do this with comments, I personally prefer using TODO and/or FIXME for things that should be fixed eventually but don't deserve a ticket, and using XXX for things I want to remember about fixing before I commit. In the heat of coding, you can write something like `// XXX: handle errors` without breaking out of the flow, like you would with a separate todo list.