How To Write Unmaintainable Code

Something light hearted How To Write Unmaintainable Code In the interests of creating employment opportunities in the programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the 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 woolly 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 isValid(x) should as a side 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 after you have no business modifying your code without thoroughly understanding every line of it. 7. In the name of efficiency, use cut/paste/clone. This works much faster than using many small reusable modules. 8. Never never put a comment on a variable. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules (e.g. total fill, must enter), when its value can be trusted etc. should be gleaned from the procedural code. If your boss forces you to write comments, lard method bodies with them, but never comment a variable, not even a temporary! 9. Try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Tip: remove all white space around operators. Good programmers can often hit the 255 character line length limit imposed by some editors. The bonus of long lines is that programmers who cannot read 6 point type must scroll to view them. 10. Cd wrttn wtht vwls s mch trsr. When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text search to understand only some aspect of your program. Consider variant spellings as a variant on the ploy, e.g. mixing International colour, with American color and dude-speak kulerz. 11. Never use an automated source code tidier to keep your code aligned. Lobby to have them banned them from your company on the grounds they create false deltas in PVCS (version control tracking). You are now free to accidentally misalign the code to give the optical illusion that bodies of loops and ifs are longer or shorter than they really are. 12. Rigidly follow the guidelines about no goto, no early returns, and no labelled breaks especially when you can increase the if/else nesting depth by at least 5 levels. 13. Use very long variable names that differ from each other by only one character, or only in upper/lower case. Wherever scope rules permit, reuse existing unrelated variable names. An ideal variable name pair is swimmer and swimner. Exploit the failure of most fonts to clearly discriminate between ilI1| or oO08 with identifier pairs like parselnt and parseInt or D0Calc and DOCalc. 14. Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables. 15. Never use local variables. Whenever you feel the temptation to use one, make it into an instance or static variable instead to unselfishly share it with all the other methods of the class. This will save you work later when other methods need similar declarations. C++ programmers can go a step further by making all variables global. 16. Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven's sake, do not write them down. Remember the words of Thumper "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired. 17. To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean write to a file, and to a print on a laser, and to display on the screen). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be unprofessional breach of the structured design principle of information hiding. 18. In naming functions, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method. 19. Never document the units of measure of any variable, input, output or parameter. e.g. feet, metres, cartons. This is not so important in bean counting, but it is very important in engineering work. As a corollary, never document the units of measure of any conversion constants, or how the values were derived. It is mild cheating, but very effective, to salt the code with some incorrect units of measure in the comments. 20. In engineering work there are two ways to code. One is to convert all inputs to S.I. (metric) units of measure, then do your calculations then convert back to various civil units of measure for output. The other is to maintain the various mixed measure systems throughout. Always choose the second. It's the American way! 21. I am going to let you in on a little-known coding secret. Exceptions are a pain in the behind. Properly-written code never fails, so exceptions are actually unnecessary. Don't waste time on them. Subclassing exceptions is for incompetents who know their code will fail. You can greatly simplify your program by having only a single try/catch in the entire application (in main) that calls System.exit()2E Just stick a perfectly standard set of throws on every method header whether they could throw any exceptions or not. 22. C compilers transform myArray[i] into *(myArray + i), which is equivalent to *(i + myArray) which is equivalent to i[myArray]. Expert

On Thu, 22 Apr 1999 14:57:08 +0100, "Watson, Paul" <Paul.Watson@bskyb.com> wrote: > >Something light hearted > >How To Write Unmaintainable Code ...snip... ROFL I am posting this on my company intranet (with proper credit, of course)...it will be required reading for all current and future programmers...... Nice job. Allen

In article <371f85fa.2645924@kiosk>, allenj@ndr.com (Allen Jantzen) wrote: > On Thu, 22 Apr 1999 14:57:08 +0100, "Watson, Paul" > <Paul.Watson@bskyb.com> wrote: > > > > >Something light hearted > > > >How To Write Unmaintainable Code > > ...snip... > > ROFL > > I am posting this on my company intranet (with proper credit, of > course)...it will be required reading for all current and future > programmers...... > > Nice job. > > Allen > > > I'd like to take the credit for it but it was sent to me, part of a job lot of jokes. Paul Watson # I don't suffer from WF Software Ltd. # stress, I'm just Tel. (+44) 1436 674729 # a carrier Fax. (+44) 1436 678693 # www.wfsoftware.co.uk

>Something light hearted > >How To Write Unmaintainable Code Great work! Let us not forget the easiest way to begin such development in earnest. When writing any application it is important when coding the first version to immediately turn the app over to the testing group. This is the ICIMBG method. It Compiled It Must Be Good. Doing this will immediately provide the opportunity for introducing variation between previously written comments and the code they refer to. Once started, the rest is easy!