CS504 Assignment No 5 Solution & Discussion Due Date: 23-01-2012

                        Guideline to avoid un-maintainable code

Unmentionable code:

                                    We all have had experience of modifying the code that one has written, either to add a new feature or fix a problem in a module. The code which is hard to understand and modify by any other programmer is said to be un-maintainable code.

Detail:

            Consider the following example to understand the above statement

Hard to understand code? nY = (nTotal-1)/nX + 1;

Is this code fragment hard for you to understand? If not, then you know the technique being used. If you do not know the technique, then it is sure frustrating to figure out. This code is one way to implement the ceil function on the nTotal/nX value. He views your code through a toilet paper tube. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything. Programmers are lulled into complacency by conventions. By every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass. Properly commenting your code is a good first step. However, keep in the back of your mind that someone else is reading your code and avoid obscure programming techniques unless they are fully commented and documented in the project. Much of the skill in writing unmentionable code is the art of naming variables and methods. They don't matter at all to the compiler. That gives you huge latitude to use them to befuddle the maintenance programmer.

Guideline to avoid un-maintainable code

1. Lie in the comments. You don’t have to actively lie, just fail to keep comments as up to date with the code.

2. Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method.

3. Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named is Valid(x) should as a side a effect convert x to binary and store the result in a database.

4. Use acronyms to keep the code terse. Real men never define acronyms; they

understand them genetically.

5. In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.

6. If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come

7. Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables. Similarly use n as a loop index.

            References.

1.                http://www.schoolstuff.be/1stelic/software_engineering/Theorie_How_to_write_unmaintable_code.pdf

2.                http://thc.org/root/phun/unmaintain.html