Coding - so what's a crime and whats a misdemeanor?
-
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...
-
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...
-
I know it's just one example, but in this case my validation code is going into it's own method.
There are only 10 types of people in the world, those who understand binary and those who don't.
But then you have the same problem within the validation method. :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
But then you have the same problem within the validation method. :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
But then you have the same problem within the validation method. :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Plus, most people want to see all validation errors at once so you would want to do the whole method anyway. :^)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Eddy Vluggen wrote:
How about a class that simply checks one thing; and call that in a loop, adding to a resultset?
How about we never work on the same code so there will be no problems. ;)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Shouldn't you ask Nagy?:~
-
Eddy Vluggen wrote:
How about a class that simply checks one thing; and call that in a loop, adding to a resultset?
How about we never work on the same code so there will be no problems. ;)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Shouldn't you ask Nagy?:~
-
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
I've used GOTO in driver development when it made sense. Generally speaking I don't use it but when it's needed there's nothing wrong with it.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Marcus Brigstocke, British Comedian
-
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...
I'm waiting for the first bank to implement Facebook single sign on.
Wrong is evil and must be defeated. - Jeff Ello
-
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...
Misdemeanor: Mixing tabs and spaces. Pick one or the other. Not using a Linting tool. Crime: In addition to not checking user input, not validating parameter input for a routine. Not checking for Null. Having two routines do the the same thing.
Jeremy Falcon
-
Eddy Vluggen wrote:
I heard that often
Lets say my application wants to see which localized satellite assemblies are installed, so it gets the names of all of the directories in the installation folder and checks which names correspond to valid Country-Culture. The
CultureInfoclass does not have a method to check if the name is valid. The way to check is to useGetCultureInfoon the directory name and catch the exception if it fails. (It could have returnednullif it fails but it doesn't!)"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
-
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.
it's often handy to leave commented-out code in place if it shows what was already tried but didn't work. if you're using a third party library, for example, and the docs lead you to think that doing X,Y,Z should work, but after talking with the authors you learn that your situation is special so you really need to do W,X,Z. seeing the incorrect (and well-labeled as incorrect!) code can steer future developers away from making the same mistake.
-
Eddy Vluggen wrote:
I heard that often
Lets say my application wants to see which localized satellite assemblies are installed, so it gets the names of all of the directories in the installation folder and checks which names correspond to valid Country-Culture. The
CultureInfoclass does not have a method to check if the name is valid. The way to check is to useGetCultureInfoon the directory name and catch the exception if it fails. (It could have returnednullif it fails but it doesn't!)"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
That is not an unexpected exception; you are actively catching the exception and continuing on a known path. That is, if you catch exactly that exception, and not just every exception. Otherwise you might miss it if the user does not have read-rights on that location; that makes for bugs that are difficult to solve, if it is unknown that an unexpected exception is occuring and therewith changing the logic of the application to some unexpected state.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
