|
|
That looks more like a ghost costume. Is he going Trick-or-Bleating? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
They would, except they're too chicken.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
To that question, Ernie vehemently retorted, "No friggin' way would I ever join that group!", what, with he being the "{insert melanin intensity level here} sheep" of the NASCAR aficionado (e.g., 'racist') herd he grew up in.
|
|
|
|
|
|
Wow!
|
|
|
|
|
|
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! 
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...
|
|
|
|
|
Concatenating constant-strings.
Swallowing exceptions.
Throwing ex;
P/Invokes copied from the web when there's a managed alternative.
..would become a long list.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I'm just waiting for the first person to put "uses JavaScript" or "uses VB".
|
|
|
|
|
Whatever happened to that whole dissing VB thing?
We didn't all inadvertently grow up, did we? 
cheers
Chris Maunder
|
|
|
|
|
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.
 Dealt with that not too long ago, .......wanted.....to....kill......
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
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.
|
|
|
|
|
Yes, I heard that often
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: I heard that often
What about when you are in the middle of a long process of sql things and then you call one SP that sets a value but is not critical to anything else. If it fails, it's OK because a separate process later on will fix it anyway. What do you do then with the exception?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I log it; I want to know *why* it failed and why I did not consider it as a possible path.
Hence the term "unexpected" - there's also some exceptions that *are* expected 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Then it sounds like the process is organized poorly. If a separate process will "fix it anyway", then why does the original stored procedure need to be done at all?
For that matter, if you've got processes that fix problems in earlier steps, then you've got a system built out of Band-Aid™s.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: then you've got a system built out of Band-Aid™s.
No, it's called dealing with 3rd party tools. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
You have my sympathy.
I hate dealing with third-party tools in our products. As the DSJB(*) I get to write our installers. I have one product that requires not one but two different versions of the Visual C++ runtime because of third-party dependencies.
(*) Departmental Sh!t-Job Boy
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: not one but two different versions of the Visual C++ runtime because of third-party dependencies.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
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 CultureInfo class does not have a method to check if the name is valid. The way to check is to use GetCultureInfo on the directory name and catch the exception if it fails. (It could have returned null if 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 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: 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.
Yes, it's the swallowing of top-level exceptions that are potentially nasty. I've had to maintain code in which top-level exceptions are swallowed and they swallowed serious errors. To track them down I then had to wade through tons of code. 
Kevin
|
|
|
|
|
Me too. I've used that method as loop control where the loop needed to go in sequence (0,1, ...) but it may be missing values. Another was for a HTML form that sends an arbitrary number of arguments - which I sequenced the naming convention but didn't have in an array. In the latter case, the exception was the only way to find the end.
But these were always deliberate.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
