Hacker News Reader

Comment by smitelli | Hacker News Reader

> "DO NOT SUBMIT"

Kinda verbose, ain't it? Just speaking from my own personal experience, usually when I resort to print-debugging I'm already pretty punchy and more likely to use a quick "ASDFASD" or similar.

View on HN

I worked on a codebase that had a special logging function with a name like NoPushLog that was just a direct wrapper of the base log function. A githook checked that this string was not in pushed code.

This solves many of the concerns raised in this thread about readability, automation, avoiding typos in the magic string.

The tricky thing you have to solve is how to push the code that defines the custom logging function, but there are solutions.

It doesn’t allow you to put that in comments, config files or other languages though like a plain text string.

Why wouldn’t it? Sounds like the git hook is probably just grep…

Then why have a function?

Because it distinguishes the normal logging function from the ones that are for local debugging.

Because of you made a typo, you're more likely to notice than in a comment or string, because it will fail, even at build time if you're using a compiled language

Right, but the whole point of DO NOT SUBMIT is that it doesn’t need to be in the compilation step. It can be in data files, comments, etc. You can change your syntax highlighting theme to spot the typos x (I added them with a keyboard shortcut anyways)

You need to compile the code with all the debugging logging in it so it can run and print out all the “got here 3”s and so forth.

I use the strings "XXX" and "999" for this (the latter because you sometimes need a dummy value in a numeric context), and have a global git hook which stops me committing a changeset which includes them.

I occasionally need to override the hook, for example when using mktemp -t, or when some floating-point data actually contains a run of 9s. But mostly, it is quite specific at catching stuff that shouldn't be checked in.

> > "DO NOT SUBMIT"

> Kinda verbose, ain't it?

I always used the word "doberman" for this purpose. I've never written code for a project that legitimately included the name of a dog variety. A simple grep for "doberman" in the production release CI pipeline catches it. If one ever did slip thru I figured it wouldn't be too offensive to anybody.

I've used NOCOMMIT. Less verbose, equally clear.

I'd be scared to spell it with one M or two Ts.

Not if a layperson comes across it and you miss an omission.

depends. If you are paranoid and afraid of dogs, ...

Yes, but you can check for "DO NOT SUBMIT" with automation.

You can't automate checking for random strings, right?

Perhaps an abbreviation would be the best of both worlds, and debug strings should be prefixed with "DNS"

You won't need to submit that particular string working at Google, right?

We could also have an acronym for the more severe "DO NOT SUBMIT - SECURITY EXPECTATIONS COMPROMISE".

DNS-SEC...

Confused sysadmins wondering if this is SOX code...

The automation which can check for do not submit itself is hard to submit. Or at least updates to it are hard to submit.

forbidden_string = "DO NOT " + "SUBMIT"

Seems easy enough?

Just disable that particular linting rule (or however it's implemented) in that repo.

Well in the LLM era, you could. I’m not sure you should :)

> You can't automate checking for random strings, right?

No, but you can make the string configurable.

Related in terms of being easy to search for, I use the abbreviation "TK" as a placeholder for text or incomplete code. Took this from the publishing industry (my partner worked in magazines) -- it's a combination that does not appear in regular English and so is easy to both see and to use search tools for.

I hope you never built a rooTKit.

TK is a semi-well known widget toolkit/GUI toolkit which came from TCL and today it's the default toolkit for Python. Nothing fancy, just basic menues/buttons and widgets, but they get the job done in a hurry.

XXX is already highlighted by most editors by default (or at least mine) and seems suitable. Any comment to be committed to a shared branch should probably contain more specifics and not contain that, if you wanted to institute a policy.

I use xyzzy

- Nothing happens

- Easy to find string in code, output, wherever

And in GNU info manuals. https://www.gnu.org/software/emacs/manual/html_node/elisp/Se... Just so happened to be reading that in the next tab.

It's about writing code that your peers can read. "DO NOT SUBMIT" is clear as day. "ASDFASD" probably does not mean "this is a debugging string" to most people.

I use "NOMERGE" plus the habit of grepping for it before I merge a branch.

They pay you enough that you'll respect the need to be professional and write "DO NOT SUBMIT" over "ASDFASD" or similar.

Not really? it’s close to the minimum string you’d be okay with never actually wanting to commit. Never had a problem with it in logs, but it could be in a comment next to the log if you did. Easy enough to add a shortcut for if you really have a problem typing it out, but at my typing speed my brain has always been the bottleneck, not the number of characters.

"GOT_HERE_1"

Reply on news.ycombinator.com