Remember your early days in programming? Did anyone tell you about the items above (and related others)? You were happy that you got the thing running - no matter how. And the exercises were toy-sized.
A project team should have the relevant team/project coding standards put into some concise guideline, if possible supported by some (maybe crude) checker tools, and have the team be aware of the guidelines.
It's the team's freedom to have strict or relaxed formatting rules. You can discuss to eternity on any such guidelines, so, do not discuss too much. Tell how it is and stick on it.
I have seeing this lately, very annoying. Programmers are defining entire function without any parameter just to execute one query. Sometimes they forget that they did it already, so they create multiple of same s t.
I do not fear of failure. I fear of giving up out of frustration.
Lately I've been reading a lot of C stuff, and I am beginning to really hate some of those guys.. no code comments, no method comments, all 1 letter variable names i.e. I, N, T, R, and function names like FNR_0(). I mean if you want to make it unreadable why not just write it in Malbolge?
Com'on, this must have been your bad day! I assume that in your good moments, you can distinguish between the writer of some code and the language. However, there is some idiomatic C/C++/C# code that uses single letter variables (see other posts) which I understand is widely accepted.
Some of that is the fault of the language. C has no namespaces, so the standard way to simulate a namespace is to prepend function names with a module abbreviation, like FNR_ in your example. However, it's still expected that the individual functions will have meaningful names within their scope, unlike the hacker who wrote your FNR_0() function. That's just bad practice, not the language.
Checking the numbers and it appears that "Terrible variable names" is leading the pack.
I wonder how a bad variable name can be considering worse by more people vs things like magic numbers, assumption of default behavior or the swallowing of errors.
I agree that all of the above are bad but something like a bad variable doesn't affect the execution of the application and in turn the appearance of poor quality to user. With today's tools and the ability to hover over a variable to get its definition the need for Hungarian notation in variables is starting to go away.
I'd say it's because the execution is only one of many important aspects of software. If you run your source code through an obfuscater it may become next to impossible to maintain afterwards. The software may execute perfectly, but if it cannot be maintained then in most cases it no use in the long term.
As for the other options, there may be specific cases where some of the others are acceptable. A trite example, but take a method which returns the centre of a Rectangle based on coords and size. Somewhere in there it's likely to have something like "width / 2". The "2" is a magic number, but replacing it with a constant is worse than leaving it as is, as what would you call it in order that it reads better than the literal value?
I don't know about the worst variable name, but as for how bad a method name can be, I did encounter GetVodka and GetWhiskey in an enterprise data procedure. Nothing to do with beverages, and nothing was returned. Instead there were hundreds of lines of procedural SQL making complex and seemingly unrelated manipulations on various datasets. Of course this was bad for a number of reasons, but if the name expressed what was intended the maintenance would have taken a fraction of the time. There's an argument there for documentation, but good names can actually be the documentation a lot of the time for the detail level stuff.