Imagine you've just gone into a new work environment and you've inherited years of somebody else's work... and they've been a bit of a lone wolf (lets be polite). You take a bit of a look around at some databases, a few stored procs, some functions, a script or two and to your horror you discover...
Whilst on the surface this seems like a bit of levity, it could be compiled into a really useful checklist to help you BEFORE you get to the point of handing over your SQL work to somebody else. We'll all have to do it one day. We can take the approach "it's not my problem anymore - worked fine for me, mostly" or we can see ourselves as custodians rather than owners and make it a goal to leave it in better shape than we found it in. To get the ball rolling here are a few of my pet hates:
- Heaps of commenting... but only the
commenting out of code that should
have been removed before going into
production. No comments that actually
explain what you're doing, why you're
doing it, when you did it and who you
are.
- Column names like field1 field1a
field2
- No test or dev environment, just
verbal instructions that "you need to
be really, really careful when you do
this".
- A work environment where nobody talks
to each other, or shares code, ideas
and so on.
- All those 400-line long case
statements that should really be
lookup tables.
- Cursors. Or more to the point, being
told to keep using them because "the
code's easier to read" than a join to
a tally table (this happened quite
recently).
- varchar(1)
- space characters and keywords in db object names
↧
