|
Having multiple return statements in a single function. 
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 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
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. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
If it gets long, sure. But it aint hard to do right.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
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.
|
|
|
|
|
..sounds like a large method with multiple responsibilities.
How about a class that simply checks one thing; and call that in a loop, adding to a resultset?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
RyanDev wrote: How about we never work on the same code so there will be no problems. 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Validation messageboxes are amateurish. And users don't like them.
The input control should limit the input to what is valid only.
How you signal input error to user is another issue, but its not like there aren't a plethora of tools available. In my system, usually, the control just takes on an "input error" back color (configurable, generally light pink).
Where there might be confusion, a custom validation message control appears below/beside/etc the control. In red.
Finally, most input error can be dispensed with by having sensible input controls.
Why on earth would you let a user type in an age?
Give them a list to choose from.
Give them 16 to 120 for Driver licence applications. 18 to 90 for porn-site account signups.
Or 0 - 15 for KidsStuff.Com signups.
Etc.
90 percent of user input can be presented as things for them to choose from, rather than let the user type it.
Except for text input like descriptions, reasons messages etc.
In which case you can't really validate - but you must filter for SQL injection!
|
|
|
|
|
Having a single return is a guideline that I mostly follow. First I aim for short functions so it tends not to be a problem. Secondly returning initially after a condition check and then again at the end is common and fine. Sometimes it actually reads better that way. But long spaghetti methods with returns all over the place is definitely a no-no.
Again, I once had to maintain some code in which the single return rule was followed slavishly. The code was mostly pretty impressive but in one case there was a bug caused precisely by slavishly adhering to this rule.
Kevin
|
|
|
|
|
Well said. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
|
Yeah...that winds me up. Particularly when they have to put effort into making it harder to use different passwords for every system. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I'm waiting for the first bank to implement Facebook single sign on.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
- 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
|
|
|
|
|
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
|
|
|
|
|
GOTO yourRoom. 
Will Rogers never met me.
|
|
|
|
|
Not freeing your pointers.
cheers
Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
