|
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.
Cheers
Andi
|
|
|
|
|
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?
|
|
|
|
|
Isn't it more of programmer's problem than the problem of the language?
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
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.
Cheers
Andi
|
|
|
|
|
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.
|
|
|
|
|
program structure , parameter checking , and behavior assumptions
how anyone can even dispute these is mind boggling .
was this a trick survey to flush out the lurker ? 
modified 13-Jul-14 4:34am.
|
|
|
|
|
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.
|
|
|
|
|
|
I name variables with i only if it's a for loop counter variable, so I will surely know what does it contain.
for (var i = 0; i < someArray.Length; i++)
{
}
|
|
|
|
|
|
That's idiomatic C/C++/C# in for loops. I agree that more descriptive names are advised, but e.g. for matrices, this is even in the text books the terms used: i, j, etc.
Cheers
Andi
PS: Naming is a difficult topic. What I disallow in any code I see: temp, or numbering variables like var1, var2, ... .
|
|
|
|
|
For me, I only use that kind of variable names in for loops. Agree on the first two and also CPallini's personal taste.
But, 5years ago, I was guilty using those variable names.
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
Copying and pasting code, above all else has to be the absolute worst coding practice. This is especially true when the programmer does not fully understand the code, and/or the code is riddled with errors.
I understand it is necessary to copy a couple of lines of code from time to time, but if you find yourself copying huge blocks of code and pasting it into the same file or project, then you should really stop and think whether or not what you are doing is right.
A well structured program should capitalize on code reuse. If you are frequently using the same block of code, then it is a good idea to write it as a function or class that can be reused throughout your application.
I have personally seen where the same block of code was pasted over 10 times in the same file (I counted 16), and each case had the same typos. This file also had over 1000 lines of code and was so complicated that I needed to break out Visio and flowchart the whole thing to understand it.
If good programming practices were used, this file should have only had about 100 lines of code, and each piece of it could be unit tested.
|
|
|
|
|
|
No comments in code, Terrible variable names, Bad / dangerous code formatting, Using magic numbers, Poor program structure and Not checking input parameters / return values / null testing leads to happening mysteries once after modifying the code.
|
|
|
|
|
|
It's always a requirement to spend more time in code cleanup, check the formatting, error checks, summary of the method and conventions used. This will really save the time in future and makes easy for other developers who will work on it.
always,
1) Find the bug,
2) Apply the solutions
3) Cleanup the code
|
|
|
|
|
4) Get out of the lab... 
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
5) Drink Beer.....
Alberto Brandolini: The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
|
|
|
|
|
3) Cleanup the code Cover your tracks
FTFY
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I thought the survey was asking what areas needed improving within my coding. 
|
|
|
|
|
People who write code (and any code so written) as if they are the only person in the world...
|
|
|
|
|
That is 100% true mate. some coders think, the written code is his lunch box.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
