Dmitry Jemerov's homepage
Dmitry Jemerov's photo   yole.ru - the e-side
English
Русский

Up

How to write unmaintainable Transact-SQL

1. First of all, do not create a separate directory for the sources. It is best to store the source code together with the sources of a project you were working on two years ago, especially if that project contains at least 200 source code files. This will make it much harder for your enemies to find and steal the sources.

2. Be creative in placing procedures in source code files. Add every new procedure in a random file, preferably in the middle. Another good trick is to sort all the procedures in the largest source file alphabetically. However, doing this too often will spoil most of the fun.

If you take all these measures, the complexity of your system will stunningly impress someone to whom you tell how the system works and show the control flow in the code.

3. Never delete anything from the code. Some day it may turn out to be useful! If a part of a procedure is no longer necessary - comment it, if an entire procedure is not necessary - leave it there. The larger your sources are, the more imposing they will look.

4. Avoid overhead caused by the EXEC statement. The more functionality you place in one procedure, the less time will be spent on calling other procedures from it. This point is especially important for the largest and the most complex procedure of your code.

5. Save keypresses and the memory of SQL Server. Never give names longer than 6 characters to variables and temporary tables. The names of the most important variables should be only one character long; choose that character randomly.

6. Another way to save SQL Server memory is to store several totally unrelated values in the same variable. On the other hand, if your procedure doesn't use any variables, it's better to have a couple of variables introduced just in case...

7. Speaking of the comments. Writing no comments at all is poor programming style. However, you shouldn't waste your precious time on writing verbose and detailed comments! Restrict yourself to the bare minimum. A good example is a comment ''/* select the values */'' before a SELECT statement. Another effective trick is to put a comment ''/* temporary procedure, used for debugging */'' before some of the most important procedures.

8. Never assign the same type to all numeric fields in a table. Be creative and try to optimize the code by assigning types with maximum variety. After all, everybody knows that cursors work too slowly!..

9. The last advice, the most important one. Remember: the undocumented features of your system are the most undocumented features in the world! The more pleasant surprises your API will contain, the more interesting the job of the programmers and testers will be!

Up