Got a minute? Refactor your code

From Scriptionary.com

Jump to: navigation, search
Author Eddy Luten
Author Link Scriptionary.com
Contributors none so far
Notes
Article was from cached search engine result. Formatting might suffer.

This recovered article might suffer from bad formatting.

In programming, changes to the source can create dirty code. Specially when working with the OOP approach, programs can become overly large; too many methods, pointers and classes can be created resulting in redundant code.

This article discusses the refactoring method that I use for my own projects, it's unofficial and they might not reflect readings found in standardized computer-science literature. Widely used resources are listed at the bottom of this page that discuss a generalized form of refactoring.


Contents


Refactoring

If your code suffers from spaghetti code it's time to refactor. Spaghetti code is code that looks extremely obfuscated, doesn't conform to structured programming methodology and should be simplified by the developer.

When this happens it's time to refactor your code. Code refactoring is a change to your code which makes it easier to:

  • Read and Understand your code;
  • Maintain modifiability of your code;
  • Increase your productivity
  • Shrink the size of your code base.

You might think I’m the only one developing my program, why should I use this 'refactoring' method?

Obfuscation

Imagine yourself 5 years from now looking at a line of code that you can't figure out. It might take you 10 minutes or more to trace all the function calls and look to up those cryptic inline ASM blocks that you forgot to comment about. Now you've wasted 10 minutes in which you could have been productive.

Dead Code

Dead code removal equals smaller binary size. An example would be unused functions that might have made sense in your initial prototype but aren’t used in your final or intermediate versions.

Equations

X*Y/32+Z is pretty hard to understand and read. While X, Y and Z might be fine variables for a vector or other data structure (see next point), the equation itself should be encapsulated like so: ( X * Y ) / ( 32 + Z ) or (X * Y) / (32 + Z) (if you don't like spaces) to maintain code-readability. Also beware that compilers might act differently based on the syntax of your equation if written obfuscated.

Variable Names

a disputed topic but important nonetheless. The only reason you should use single letter variables is to specify for loop iterators, X, Y, Z and W coordinates in Vectors, points, matrices and other positional structures. Usage of single letter variables is not a good practice and dramatically decreases code readability and debug-ability. Nested for loops can contain many different single-letter iterators which can make your code seem quite messy.

Comment Only Where Required

While most of your code should be self explanatory, some code (specifically ASM code) can cause severe obfuscation. Make sure that you comment on this type of code if it is not possible to make your code readable to make sure that you will be able to understand the functionality upon review. It is not necessary to comment on self-explanatory function calls, e.g.: void Destroy(); //Destroys the object is an example of an extremely redundant comment.

The One-Man Show

While I could write an entire article on this point I'm going to lay out a ground rule for programmers who work alone. Be your own manager. This means that you'll have to kick yourself every once in a while to refactor your code, make sure that performance is optimal and that you don't stray off topic whilst looking things up from a reference. It's very important to stay on topic when programming since it's easy to close the file you're currently working on and create a new file based upon a new idea you just had. Finish what you've started and finish it logically; ADD is your enemy.

Productivity, Productivity, Productivity

Staying productive during the development of your project is important to keep you focussed on the tasks at hand. Obfuscated code doesn't aid in this process. Endless lookups and references to definition-files are extremely counter-productive especially if you are facing a deadline. Keep refactoring in mind as you develop your project, reuse existing code where possible and do not code without thinking about the implications that a certain function might have to the overall usability of your code.

Refactoring "Extract Method"

By using the "Extract Method" you break a large method into several smaller methods making the function easier to read and creates methods which in term can be reused by other methods (OOP fundamentals).

Refactoring "Rename Method"

The "Rename Method" urges you to change the name of a method into something more suitable to the method’s functionality. Methods such as void incrcnt(); are cryptic in their nature, a better name for this method would be void incrementCount();.

If you wish to learn more about refactoring (the official form), visit the following resources.

External Links

Retrieved from "http://scriptionary.com/Got_a_minute%3F_Refactor_your_code"
Personal tools