Felix Geisendorfer is taking an interesting approach to defining programming in this new post to the Debuggable blog - he's coming at it more from the level of the perception the programmer has about writing good code.

I believe understanding the patterns in your own thinking will by far make the biggest impact on how good you will get as a programmer. Forget design patterns, forget unit testing, forget all those functions you know. Important is to question why they exist and how they could be improved.

He illustrates through a few examples what he means. He describes one such thought method, the "return home early" process - basically, if something looks too complex for its own good, it probably is. He offers a different way of thinking about it too, a more visual way that can help simplify things even more by laying out the pieces and seeing where they all fit.

Unit testing in PHP applications is growing more and more in popularity, so much so that some developers get into it, test all of their code and aren't exactly sure when enough is enough. Jim Plush has a suggestion for those kinds of testers - consider the cyclomatic complexity.

It's one of the most common questions you ask when you first start using Test Driven Development or Unit Testing in general... When am I done?

It's the point you feel confident when all your tests exercise the code in your classes. How do I know when that point is? I've come across a new way of finding this point using something called cyclomatic complexity. Developed by Thomas McCabe in the 70's cyclomatic complexity is a simple measurement of how complex a piece of code is. One of the nice parts of it is that you can use it when working with unit tests.

To illustrate, he gives a simple example of a function with only a function call and return inside. This has a cyclomatic complexity rating of 1 (the lowest). Now, start adding in ifs, loops, and other ways for the data to go and you start adding more complexity levels. Jim suggests that this can be another useful unit testing measurement - one more unit test for each level of complexity.

He also notes a pleasant side effect of this sort of classification:

The other nice part of a CC number is you can quickly find out when a method is ripe for refactoring. If you have a method with a CC number of 20 you know you most likely have a problem on your hand.