Ever wonder what an extremely bad naming convention for your source files (.java, .jsp, etc.) would be? Well here's one. Name them after the use case (or step of the use case) whose functionality that the source is designed to represent. (ex. UC10_02.java) You might think it's clever or it might save you from having to be clever with naming your files, but it's a bad idea.
Why is this so bad? Well, just imagine the maintenance nightmare that you are creating. In this scenario the names of the source files do not give the code maintainer a hint about what they do without the list of use cases. So, there can be no educated guessing as to where the problem the maintainer is trying to fix might be lurking. She will have to cross-reference the list of use cases with the file names to try to figure out what every source file is doing. BAD! Imagine having to do that yourself.
A second reason this is bad is because it implies that every file only incorporates functionality from a single use case. I'm sure I'm getting ready to tread on someone's holy ground here, but I think this is BAD! It is not uncommon for more than one use case to be represented in a single class. Consider the use cases of Log In and "log out". I believe that the functionality in both of those use cases could be represented in a single servlet and that it may make sense to.
I have actually witnessed an application that has followed the naming convention above. I cringe when I think of having to maintain it. Fortunately I don't have to.
If this still sounds like a good idea to you, please see How to Write Unmaintainable Code. Roedy Green has compiled several tips that you can follow to further obfuscate your source code.
5:48:38 PM
|