Coding - so what's a crime and whats a misdemeanor?
-
harold aptroot wrote:
Committing commented-out code.
That's called good practice. :-\ Actually, there have been times when business requirements went back to what they were before and so uncommenting the code was quite simple. I don't leave commented code in forever though. After a certain amount of time passes, it can go.
There are only 10 types of people in the world, those who understand binary and those who don't.
One of the biggest dangers in software development is when code gets into the code base without first going through the human brain. Un-commenting a block that looks like it shouldn't be commented out is a classic way that this occurs.
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
If we're talking QA Misdemeanour * expecting someone to be able to solve your null reference problem * doesn't work * sending email through gmail * I get an error (no I'm not telling you what it is) * any kind of casting problem * ToString() on a string * attempting to code in MVC without understanding HTTP * thinking that setting the MIME type of your response to "application/vnd.ms-excel" is "creating an Excel spread sheet" Crime * posting 100 lines of code and expecting someone to be able to solve your null reference problem without even saying what line it happens on * when sending email getting a perfectly understandable error like "Authentication failed" and asking for the code to fix it * any kind of casting problem where you expect a stranger to understand what you mean and not what you say * any question that is effectively "how do I write a website" * any question regarding the generation of PDF files * any question regarding the generation of Excel files * any question regarding the generation of Word files * asking how to store dates in SQL in a given format
-
Eddy Vluggen wrote:
I heard that often :rolleyes:
What about when you are in the middle of a long process of sql things and then you call one SP that sets a value but is not critical to anything else. If it fails, it's OK because a separate process later on will fix it anyway. What do you do then with the exception?
There are only 10 types of people in the world, those who understand binary and those who don't.
-
One of the biggest dangers in software development is when code gets into the code base without first going through the human brain. Un-commenting a block that looks like it shouldn't be commented out is a classic way that this occurs.
Duncan Edwards Jones wrote:
Un-commenting a block that looks like it shouldn't be commented out is a classic way that this occurs.
Never heard of someone doing that. If you thought that was what I was suggesting, you misread.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Having multiple return statements in a single function. :thumbsdown:
There are only 10 types of people in the world, those who understand binary and those who don't.
Now there's an old idea that is hard to defend; yes, I agree, you have to know when to break the rules. I'd rather see a return from a switch then someone using goto's simply to have a single exit-point. I detest the "Goto error, goto exit"-pattern from VB.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Misdemeanour: CVDD (Curriculum Vitae driven development) - implementing a technology or architecture just to say you did. (This isn't always a crime though - sometimes it helps shake the slurry out of the system)
-
Duncan Edwards Jones wrote:
Un-commenting a block that looks like it shouldn't be commented out is a classic way that this occurs.
Never heard of someone doing that. If you thought that was what I was suggesting, you misread.
There are only 10 types of people in the world, those who understand binary and those who don't.
No - I'm suggesting it can happen if code is commented out and then the result checked into source control....
-
Eddy Vluggen wrote:
I heard that often :rolleyes:
What about when you are in the middle of a long process of sql things and then you call one SP that sets a value but is not critical to anything else. If it fails, it's OK because a separate process later on will fix it anyway. What do you do then with the exception?
There are only 10 types of people in the world, those who understand binary and those who don't.
I log it; I want to know *why* it failed and why I did not consider it as a possible path. Hence the term "unexpected" - there's also some exceptions that *are* expected :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Now there's an old idea that is hard to defend; yes, I agree, you have to know when to break the rules. I'd rather see a return from a switch then someone using goto's simply to have a single exit-point. I detest the "Goto error, goto exit"-pattern from VB.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
I detest the "Goto error, goto exit"-pattern from VB.
I wonder where this hatred has come from. I did plenty of programming in VB6 and GOTO was a go to statement. It seems like some of y'all lose sleep over thinking about GOTO. Let it go. :-\
There are only 10 types of people in the world, those who understand binary and those who don't.
-
harold aptroot wrote:
Committing commented-out code.
That's called good practice. :-\ Actually, there have been times when business requirements went back to what they were before and so uncommenting the code was quite simple. I don't leave commented code in forever though. After a certain amount of time passes, it can go.
There are only 10 types of people in the world, those who understand binary and those who don't.
Any code that has implemented some sort of source control shouldn't have any commented code. If your customer wanted to go back to previous functionality, you should review the source code history to retrieve it from there, it should even be wrapped up in a single check-in with all the dependencies that the functionality relies on. You can comment code during development to test other avenues, in fact, I think can use whatever coding practice you like while developing :-\ but it shouldn't get committed into the code base. Sorry if this comes across a bit sour, but I'm working at a place that used to use commented code as source control... They have source control now, but they haven't grasped the concept very well and the code is littered with obsolete, misleading and blatantly wrong comments :wtf: :mad: So... crime.
-
That's why I added the second sentence.
Wrong is evil and must be defeated. - Jeff Ello
mmmm... ok. I forgive you ;P :laugh: :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Was just adding something in QA and I thought: there are things no sentient coder should do these days, but every day in QA we see some halfwit doing them. So I figure we need a list of Crimes and Misdemeanors, and these are my first candidates. Misdemeanors are "smack on the head" offenses, Crimes deserve a death sentence! :laugh: Misdemeanors: A) Ignoring existing standards and modifying someone else's code "your way". Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile. Anyone want to add to these?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
- using hardcoded "magic numbers" instead of resonable start/end values - throwing a general (empty) exception in a catch block instead of handling the one caught - duplicate code instead of using a method for that - using misleading/ambiguous variable names
-
Misdemeanour: CVDD (Curriculum Vitae driven development) - implementing a technology or architecture just to say you did. (This isn't always a crime though - sometimes it helps shake the slurry out of the system)
Duncan Edwards Jones wrote:
CVDD (Curriculum Vitae driven development) - implementing a technology or architecture just to say you did.
I like that! Committed to vocabulary.
Regards, Rob Philpott.
-
D.1) Storing "numbers" as integers just because they're called numbers. (Telephone numbers, social security numbers, etc.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
+24
-
harold aptroot wrote:
Committing commented-out code
We don't do this in our shop - a big no-no. That is what Source control is for.
-
Eddy Vluggen wrote:
I detest the "Goto error, goto exit"-pattern from VB.
I wonder where this hatred has come from. I did plenty of programming in VB6 and GOTO was a go to statement. It seems like some of y'all lose sleep over thinking about GOTO. Let it go. :-\
There are only 10 types of people in the world, those who understand binary and those who don't.
In the context of VB, I agree. GOTO was/is there for a reason.
-
Any code that has implemented some sort of source control shouldn't have any commented code. If your customer wanted to go back to previous functionality, you should review the source code history to retrieve it from there, it should even be wrapped up in a single check-in with all the dependencies that the functionality relies on. You can comment code during development to test other avenues, in fact, I think can use whatever coding practice you like while developing :-\ but it shouldn't get committed into the code base. Sorry if this comes across a bit sour, but I'm working at a place that used to use commented code as source control... They have source control now, but they haven't grasped the concept very well and the code is littered with obsolete, misleading and blatantly wrong comments :wtf: :mad: So... crime.
:thumbsup:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
OriginalGriff wrote:
Crimes: A) Storing passwords in plain text: CommitStrip[^] B) Leaving your code open to SQL Injection: XKCD[^] C) Committing code that doesn't compile.
Crimes Starting Alphabetically 'numbered' lists
Normally, I wouldn't - but I didn't want to influence people into the "zero- or one- based lists" argument with both being crimes, probably...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Having multiple return statements in a single function. :thumbsdown:
There are only 10 types of people in the world, those who understand binary and those who don't.
I'd disagree with this: I'd far rather see validation failures causing an immediate return then over indented cr@p to avoid it:
int age;
if (!int.TryParse(tbAge.Text, out age) && age > 0 && age < 150)
{
MessageBox.Show("Age must be an integral value between 1 and 150");
return;
}
...int age;
if (!int.TryParse(tbAge.Text, out age) && age > 0 && age < 150)
{
MessageBox.Show("Age must be an integral value between 1 and 150");
}
else
{
...You can get away with that for one level, but when you are validating a dozen inputs? Return is a cleaner way to do it, IMO.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Using a script to prevent users from pasting passwords into your login form, and then claiming it's for their own good. :doh: It's not about "supporting password managers", it's about not consciously breaking security | Troy Hunt[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Yeah...that winds me up. Particularly when they have to put effort into making it harder to use different passwords for every system. :mad:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
