Coding - so what's a crime and whats a misdemeanor?
-
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...
Code that is complex by how its written rather than by it complexity of the problem
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
D) Use GOTO. E) Systems Hungarian But I'd like to add, that you also need to know when to break the rules.
Wrong is evil and must be defeated. - Jeff Ello
GOTO can be useful and there are moments where it is needed. Misusing it can result in spagetti code I know but... I would like to see you coding in LAP (PLC) or assembly without JMP instructions...
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...
Well according to the BBC, the recent Talk Talk hack was a simple SQL injection. This from an 'internet' company. Talk Talk is criminal, sounds right to me. Committing code that doesn't compile can just be a case of not including a file, so I'd say that was a misdemeanor. TFS will kindly do this for you at its will. Personally I'd say excessive use of design patterns turning the simple into the multifaceted complex is a crime. Any type that has the word 'helper' in its title- Crime. var - Crime Indentation with spaces - Crime More than 1 type per file - Crime Inconsistent naming - Crime
Regards, Rob Philpott.
-
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...
OriginalGriff wrote:
A) Storing passwords in plain text: CommitStrip[^]
Which is why my password is 08A168B215C2f1 - that way I can store it in a public variable and nobody knows that it's not encrypted ;P ... until now... :sigh:
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
D) Use GOTO. E) Systems Hungarian But I'd like to add, that you also need to know when to break the rules.
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
D) Use GOTO.
so
breakandreturnare not to be used?“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Eddy Vluggen wrote:
Swallowing exceptions.
:mad::mad::mad: Dealt with that not too long ago, .......wanted.....to....kill......
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
-
GOTO can be useful and there are moments where it is needed. Misusing it can result in spagetti code I know but... I would like to see you coding in LAP (PLC) or assembly without JMP instructions...
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.
That's why I added the second sentence.
Wrong is evil and must be defeated. - Jeff Ello
-
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.
-
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...
-
Jörgen Andersson wrote:
D) Use GOTO.
so
breakandreturnare not to be used?“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
They all become jumps in the end. Breaks, returns and exits have a quite lower probability of becoming pasta.
Wrong is evil and must be defeated. - Jeff Ello
-
D) Storing numbers and datetimes as string in database / counfounding a value with its string representation. E) Not reading the documentation of the objets used in the application. F) Not checking/validating user inputs. G) Copy-pasting a code from anywhere on Internet and expecting it to work without having to think about the requirement ; asking someone else to solve the problem when copied code does not behave the exact desired way (without defining the correct behaviour whatsoever).
I never finish anyth
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
-
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
-
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 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
-
Eddy Vluggen wrote:
Swallowing exceptions.
Some exceptions are OK to ignore. :^)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
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.
-
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
-
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)
