The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Well, if I'm writing a very short procedure purely as a way to check it works or compare two methods that have occurred to me, and am probably doing it in a test rig, then yes, I will use short variable names for speed. But I do it properly when I rewrite the code into the actual program.
One thing I will admit to: if I write a short utility function, one or two lines... you know, to return a filename without the extension, or the nth word in a string or something... I will often use astr, x etc. And counters are i. Always. Unless there is a nested loop, in which case one of them is j. Unless the code is long and complicated, in which case one is outer and the other inner.
Should I hang my head in shame? [Please specify precise angle]
When learning the language (C++) I utilize class names cfoobar cgoobar and choobar as needed. Never needed a cjoobar. Also as per FORTRAN i often utilize i j k for loop counters. Otherwise I utilize descriptive variable names even lengthy ones unless the lengthy type name is conveniently nearby to provide the context.
I don't object to others doing that, but to think about code I do better to "think in code". So the comments about "habits" really apply here. If any identifier is unconventional/silly I won't be focused on the intent of the code.
Secondly - the code that I do as a "one-off" often turns out to be useful and adopted in another project or context. It drags down my time and effort if I need to go back and tidy up and refactor.
Lastly - I was part of a moderately sized audience for a product demonstration once. As often happens the "presentation gods" were unkind. The demo started going awry and exposing all kinds of errors, exposing dopey-silly stuff that the developers probably NEVER intended to be part of a marketing demo.
I felt awful for the marketing guy that had to tap dance around to try to save this humiliating, failing pitch.
1) I need to change something in a database, that is really complicated to do using only SQL instructions.
2) Using any of my programs, I create a new button. I never use the name proposed by Visual Studio, but in this case it does not matter
3) I create the code I need to modify the database (Read data, change it, write it back)
4) I run the program and go to the module that has my button.
4a) Of course, I press the button.
5) The job is carried on.
6) I stop the program.
7) I delete the button
That's it. The button's life is just the time it takes to change my database. (Or whatever stuff must be done)
I think you should always make the decision before you code: Is it one-way disposable code or is it production-level clean code. The latter can take up to twice as much time, so you should decide carefully. So when you decide to use throw-away code in production, you *have* to invest some more time to make it nice and neat. At least that's the way I do it.
SO ?For that matter, as an ironic note, you reply servers no constructive purpose, either.
Perhaps, IF in your vast experiences, you can add your views of your time spent there? ELSE, that old saying can well be said: "Physician, heal thyself!"