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...
- Using camelCase when not using Hungarian. 1) Using Hungarian.
-
Unsorted pick lists and dropdowns. This kind of thing is easy enough for even a blank slate intern to get right.
Do what thou wilt shall be the whole of the Law. - Liber AL vel Legis 1:40, Aleister Crowley
DropDowns with more than a dozen items or only two items. DropDowns for numbers. Three DropDowns instead of a single DateTimePicker.
-
No, Apps Hungarian is the better of the two. But not by much. http://www.joelonsoftware.com/articles/Wrong.html[^]
-
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
Those are not
gotos. Aside: While simplifying some code this week I removed aswitch(that was inside awhile) ... and later realized that I hadn't removed abreakthat was left over. :doh: I really dislike thatbreakoperates onswitch-- I hope DMR's harp gives him blisters. -
No, Apps Hungarian is the better of the two. But not by much. http://www.joelonsoftware.com/articles/Wrong.html[^]
That is Joels' take. I rather not see prefixes at all. I can imagine the type, if you're reading from a printout and taking a ... walk, but not "Apps", where different abs got different meanings for each product.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
That is Joels' take. I rather not see prefixes at all. I can imagine the type, if you're reading from a printout and taking a ... walk, but not "Apps", where different abs got different meanings for each product.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
where different abs got different meanings for each product.
That's the whole point.
-
Those are not
gotos. Aside: While simplifying some code this week I removed aswitch(that was inside awhile) ... and later realized that I hadn't removed abreakthat was left over. :doh: I really dislike thatbreakoperates onswitch-- I hope DMR's harp gives him blisters.True - back when I was at university in the late 80's we were taught 'structured programming' and anything that threw you out of an iteration was forbidden, until year two when we were told that there were circumstances where there was not other option.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
True - back when I was at university in the late 80's we were taught 'structured programming' and anything that threw you out of an iteration was forbidden, until year two when we were told that there were circumstances where there was not other option.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
anything that threw you out of an iteration was forbidden
But
breakgoes only to the end, not somewhere completely different, it's structured (still prefer to avoid it though). -
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
Hear! Hear!
-
It will be in the source code history.
Kevin
But where? And why was it removed?
-
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.
-
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...
Some crimes I've seen in the last few years: A) Introducing dependencies without checking to see if they're reliable. B) Introducing dependencies that are just a C# wrapper around a REST API. C) Deciding that automating builds/deployments isn't worth the time. D) Manually deploying changes to production without committing them to source control (after which of course you go on leave). F) Being a lead developer and insisting that all columns in a database be nullable. G) Giving full sa/admin/root permissions to someone/something because you don't know what permissions it actually needs - have to confess I've been guilty of this in the past. H) Using {PopularFramework}.js because it's popular I can't seem to think of any misdemeanours though.
-
Well, my whole system does nothing but Throw (not Throw Ex, or Throw New Ex). At the top there is an unhandled exception handler, which: - Shows the error in a message box - On OK it closes the current program down - Waits several seconds, then - restarts the program and puts the user back to (roughly) where they were. The users prefer that, and there have been very few cases where they got stuck in a loop. When it did happen, I soon heard about it. Almost every time they got what they call a "restart", was due to some kind of service fail, LAN, DB, internet, etc. Most of which self righted fairly quickly.
-
I'm just waiting for the first person to put "uses JavaScript" or "uses VB".
The diss JavaScript people must be fairly stupid by now. And the whole dissing VB always seemed so childish. Especially from C# programmers. "Hey look at me, I code in .Net, but I'm not one of those VB cretins - I'm cool like you guys".
-
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.
Not so sure. If ever that was the case, what is the downside of handling it anyway? Surely less than the downside of being wrong about that exception being able to be ignored. And always remember, in .Net you can get a huge performance whack catching and swallowing exceptions (especially DB exceptions).
-
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
More to the point: I have not seen a GoTo in the wild since VB6 - and even then only for err handling (On Err Goto). I would seriously doubt that GoTo is a real problem in any .Net shop.
-
Well, I always leave the commented out code there. If I see I any commented out code more than a week old, I delete it. (because obviously the new code didn't break the system, and the old code can always be retrieved anyway) (the only reason to leave the commented out code there is, if your commits breaks the build, or crashes the app the next day, you can readily reverse the mod - and you will still remember WTF it was all about).
-
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...
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!
-
Some crimes I've seen in the last few years: A) Introducing dependencies without checking to see if they're reliable. B) Introducing dependencies that are just a C# wrapper around a REST API. C) Deciding that automating builds/deployments isn't worth the time. D) Manually deploying changes to production without committing them to source control (after which of course you go on leave). F) Being a lead developer and insisting that all columns in a database be nullable. G) Giving full sa/admin/root permissions to someone/something because you don't know what permissions it actually needs - have to confess I've been guilty of this in the past. H) Using {PopularFramework}.js because it's popular I can't seem to think of any misdemeanours though.
On C) I detest fully automated Build/Deploy. Build to Dev (automatic on commit). Deploy to Test as a non-automatic function (ie, someone has to press the button). Deploy from Test to Live ditto. Whoever pressed the button has to respond to the user calls when it crashes.
-
Some crimes I've seen in the last few years: A) Introducing dependencies without checking to see if they're reliable. B) Introducing dependencies that are just a C# wrapper around a REST API. C) Deciding that automating builds/deployments isn't worth the time. D) Manually deploying changes to production without committing them to source control (after which of course you go on leave). F) Being a lead developer and insisting that all columns in a database be nullable. G) Giving full sa/admin/root permissions to someone/something because you don't know what permissions it actually needs - have to confess I've been guilty of this in the past. H) Using {PopularFramework}.js because it's popular I can't seem to think of any misdemeanours though.
On F): I really don't like nullable columns. In the last couple years I have set every single column (except date columns) to NOT NULL - but always with a default value (0 for numbers, '' for strings, 0 for bit etc). I thought maybe the Default thing would slow the DB down. Nope (MS-SQL Server 2012). I figured I would discover some logic errors just as bad as Null errors. Nope. All good :)
