|
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
|
|
|
|
|
I can't believe you missed the "u" in "Misdemeanours". From what I know, Brits love "their" grammar.
My additions:
Misdemeanours:
n) Unnecessary async wrappers for synchronous methods
n+1) Abusing var (for C#)
n+2) Under-usage of sealed (for C#)
Crimes:
n) Spawning unnecessary threads
n+1) Using dynamic for "predictable" types (for C#)
n+2) Making everything "public" with no thoughts whatsoever
I ain't got no signature.
|
|
|
|
|
I can think of lots, but most has been covered.
Here's two crimes that make me cringe:
- Bad comments (which is most), like commenting the obvious, wrong comments, comments with bad spelling and/or grammar, etc.
- Christmas tree coding. if (...) { if (...) { if { ... } else if { ... } } else if { ... } } } Something like that (add a few layers, format it nicely and it'll start to look like a Christmas tree).
- Just usage of a lot of if's in general.
|
|
|
|
|
I often get accused of commenting the obvious but I was taught to, and still do for complex algorithms/methods write what I want to do in terms of words as a comment (my intended function).
Then I write the code underneath. The comments were there before the code, so it'd take me more time to delete them.
Sorry - if you find it hard to just scroll past that stuff...
|
|
|
|
|
What people forget is that each comment is a line of code that has to be as carefully written as everything else and that if the code changes so should the comments.
In the end, if there's lots of bad comments, people learn to ignore comments and miss the actual good comments!
I've actually written a tip about it, Write comments that matter[^], because I see so many comments that add absolutely nothing to the code.
I haven't seen your code, so I don't know if you do any of the stuff I describe in the tip, but if you do I ask you, for the sake of programmers everywhere, please reconsider this bad habit of yours!
|
|
|
|