Monday, March 31, 2008

Refactoring and Cyclomatic Complexity

"Refactoring" by Martin Fowler is a great book that gives formal definition to a huge mishmash of informal programming procedures and habits. It not only argues the benefits and "whys" of the whole refactoring game (which are often informally understood and championed by many), but also gives formal definition to the types of code decay most often occurring as well as formal definitions and names to the possible solutions.

Fowler lovingly refers to this code decay as "code pungency" or "bad smells in code" when encountered by a developer. However in 1976 Thomas McCabe coined the term "Cyclomatic Complexity" in a paper outlining a software metric used to analyze the complexity of programs. The metric measures the number of linearly independent paths through a given chunk of source code.

"Cyclomatic complexity is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command." [wikipedia]

Basically as the number of conditional statements in a program grows, so do the number of corresponding paths and therefore the graphical representation of the program's control flow. A program with no if/else statements has a single path. Add in one 'if' statement and the number of paths grows to two. One path if the 'if' returns false, and another if it returns true. Any function call including some sort of boolean assessment will fork the program's path, not to mention 'while' and 'switch/case' statements, ad infinitum.

The software metric of cyclomatic complexity serves as a baseline indicator for when a program needs refactoring. From a top level viewpoint the analysis is useless because all programs must include some degree of complexity in order to be useful. Where the measurement become useful is at the method level where methods including some 30 or more linearly independent paths are clearly marked as overly complex and should be scheduled for refactoring.

Several tools exist which do good jobs of measuring this metric:
[JavaNCSS]
[Dependency Finder]

One which includes an excellent visual output of the state of a project's complexity is Panopticode, which also provides visual output of your given level of code coverage as a bonus.

Example: The complexity state of the Cruise Control 2.6 project (hit refresh until it loads).

All in all refactoring is an extremely necessary concept for every programmer to understand, even those who practice it now stand to gain a great deal by understanding why they are doing what they do. I hope to find other refactoring tools to aid in the developmental process soon.

Monday, March 17, 2008

The Power of Faith vs The Crushing grip of Reason

A central theme in Lost is the modern personification of the conflict between Faith and Reason. I find this duality to be personified on a day to day basis through my experiences with modern technology and computer science.

The preparation for the upcoming first day at the new job has thus far been an attempt to balance the theoretical with the practical. Reading books such as Code Complete and The Mythical Man Month represent the theory side, while the practical side is a mishmash of Rails hacking and beginner .net, VB and C# tutorials. Should I have faith in my abilities to pickup new technologies and learn as much practical theory as possible, or should reason prevail and should I focus more on learning the physical construction tools personified by languages and IDE's. Of course in practice there is no picking and choosing because practicality must be combined with theory in order to be a complete programmer. So then is there also a balance to be found between faith and reason? Is there a difference??? Or is science just a higher form of religion in who's laws and postulates we steadfastly believe until they are overturned.

Again everything streams toward balance, like sliding down the strings held by some gigantic blindfolded woman of justice onto her scales. I must be empowered to balance myself.

"Trying to find a balance, trying to build a balance." - Slug

Sunday, March 16, 2008

The Mythical Man Month

It's interesting to reflect how much and how little has changed in the past 30 years since The Mythical Man Month was written. The current chapter I just finished reading, regarding the idea that change is an inevitability resonated with me very clearly. The idea that the actual task of any programmer is to realize a vision for a program consumer and deliver to them a semblance of satisfaction rather than any physical program, that the program itself as a physical object only quantizes and represents the customer's desire for change was fascinating.

So not only is change inevitable its also a product one must become accustomed to delivering.

Progress with becoming a prolific rails developer is proceeding at a decent pace. At first its quite unnerving how much work is done in the background via ruby scripts, but at the same time that nervousness is offset by excitement for the power of the rails platform. There is an unbelievable amount of things automatically built into rails, not only interoperability but programming practices as well. DB migrations are akin to version control, the entire MVC architecture. Working on session handling and error correction at the present moment. Proving to be very exciting.