The Weird and The Wonderful

The Weird and The Wonderful forum is a place to post Coding Horrors,
Worst Practices, and the occasional flash of brilliance.

We all come across code that simply boggles the mind. Lazy kludges, embarrasing mistakes, horrid
workarounds and developers just not quite getting it. And then somedays we come across - or write -
the truly sublime.

Post your Best, your worst, and your most interesting. But please - no
programming questions . This forum is purely for amusement and discussions on code snippets. All
actual programming questions will be removed.

The problem is that he's looking up the department by either account number or category ID. This is just bad practice and made worse by the fact (which I forgot to mention) that the PROC's name is "GetClientDepartments" which implies the list is being filtered by clients, not my accounts or categories.

There should be at least two PROC's, one called "GetDepartmentsByAccountNumber" and the other "GetDepartmentsByCategory". It's just plain laziness that he put the functionality for two very different things into one proc.

Now get this -- on the client side, he's always populating the department and catid values!

Well in that case it's A BIT weird.
I've worked with such procedures a lot. They usually were part of some bigger procedure. This, for example, could be part of getting a product, but depending on the department and available data and some customer setting and lots of other stuff you would ultimately get 1 out of maybe 10 possible outcomes.
Anyway, if you worked where I worked (notice past tense!) this wouldn't bother you as much as it does

You should replace the "4" with a value that you get from a settings-table ofcourse. You don't want to recompile your sproc simply because the length of catids' change. Better yet, replace it with the MIN(LEN(accountnumber)).

I was having a code review session and found out that the password is just being hashed and stored in the db. The db had a field for salt when i designed it and I specifically asked to use the salted hashes. So i suggested the developer to use the salted hash and he agreed. Later i asked him and he said he implemented it.

Now 3 months later I am working on some query optimization and during this i run a query on the user table and to my surprise the salt field contains "mmmmmm Salty passwords..." for all the records. And when i checked the code, the code contains this hard coded string in register action method (asp.net MVC).

Good thing is that the developer left the organization otherwise I would have been serving a life sentence for killing him.

At my former employer we had a small config app with such a password baked into the code.
It ran with all our clients on many computers.
The regular user couldn't change the configs and we, and admins at the customers, always knew the password.
A bit more secure than a regular config file or a non-password protected config app.
It did the job!
I wouldn't use it on a website or anything though