2011/11/14

The art of refuctoring

I recently saw @jasongorman present at JaxLondon on refuctoring. Unlike refactoring you try and reduce the readability of code to make you indispensable to your employer.


Here are my top ten 'refuctorings' in no particular order:



  1. Prefix all class names with the name of your employer and at least one TLA.

  2. Include @note comments in your file stating that the code must be thread safe. Then implement it in a way that is unsafe for multi threaded use.

  3. Prefix all member variables with either m_, s_ or p_, try your best not to follow the convention for their meanings i.e. use s_ (static) on non static private member variables.

  4. Make sure that you inherit all of your member variables from a parent class.

  5. Use bit level logic as much as you can, especially in application high level application code.

  6. Only write a comment if it is misleading: Include jokes like 'this method could blow our memory' to make the caller think twice before using it.

  7. Copy and paste public static methods between classes, take the time to rename them, reformat the layout and generally make it hard for static analysis to realise it is the same code.

  8. Avoid using brackets on if statements, just indent code after the first line to make it look like it is part of the if block.

  9. Optimise your code by manually in-lining supporting methods to increase the size of your code. Don't forget to take the time to change the variable names and layout.

  10. All methods should be at least 500 lines with fully expanded if statements nested as deeply as possible. If you have some if statements in your pre-amble of a method why not repeat those tests throughout the code.


The most important thing to remember is that you need a really good unit test suite so that you can make all of these changes, safe in the knowledge that you have not broken the code.


The idea of the exercise is to try and make you think of ways that you could make code worse without breaking it. It is amazing how many anti patterns you can come up with as part of this exercise. I can highly recommend the session with Jason.


For more information on the courses Jason offers see his website Codemanship