|
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...
|
|
|
|
|
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
|
|
|
|
|
Reminds me of my tech leads description of my code...
I still think that it's necessary to write some code using reflection to generate a JavaScript file to be added dynamically during application startup to a web optimization bundle to declare AngularJS references to some Web API Controllers so that I can save myself ten minutes of copy-pasting every few weeks when I need a new Controller.
|
|
|
|
|
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.
|
|
|
|
|
Indentation with tabs: Crime.
Sometimes I will read code in Notepad, and there the tab spacing is just too large.
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: Sometimes I will read code in Notepad,
Not just a crime, but also an obscenity. You can't blame tabs for an editor knocked together one afternoon after a liquid lunch in 1985.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: var - Crime
why would that be? When using Linq, you often use var.
Rob Philpott wrote: Indentation with spaces - Crime
Where I work, we indent using spaces Should we be put to death?
Best,
John
|
|
|
|
|
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 ... until now...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
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.
|
|
|
|
|