It’s been some time now that I’ve taken upon coding on an application that someone else’s built. Now that’s not unusual, I have done so on many other projects. What makes this endevour quite unlike many others is that it has made me realize how often we can find bad code. Sorry, scratch that, I mean really bad code.

It’s not bad code as a result of ignorance, but worst, because of bad habit. Actually, scratch that too. I would say malice. Take this PHP class:

class SomeClass {
	function someFunction($parameter = null) {
		// If the parameter is 1
		if ($parameter == 1) {
			// Launch a passing parameter
			return $this->__launchA($parameter);
		} else {
			// Give back error
			$this->error = 'Not good';
		}

		// Launch the default function sending parameter
		$value = $this->__launchDefault($parameter);

		// If value returned is ok, give it back
		if ($value > 2) {
			return $value;
		}

		// If not valid, return false
		return false;
	}

	function __launchA($parameter = null) {
		// Take action based on $parameter
		switch($parameter) {
			// If it's 2
			case 2:
				return 2;
			default:
				return $this->__launchDefault($parameter);

		}
	}

	// ...
}

Because of some NDA agreement that I have signed, I’m actually mocking what I have to deal with every day. But trust me, it’s much worst than this. Get the picture? A huge chain of private methods, calling each other, and a comment ratio *way* about what is acceptable (what good is it if on a comment you are actually explaining what a very simple if statement is doing?). Now, you may be asking yourself, why do I call this (crappy) code malice? Because it is meant to generate mode source code lines. Therefore: more money to charge to the client.

I have seen this over and over lately, on a very big project I’m working on. And the truth is, as a member of an outsourcing software developing firm, I’ve come to realize that us (freelance developers) should be accountable for such bad code. The one who produced this kind of crappy code should be made accountable for the amount of hours it takes to refactor their code, and make it actually usable.

UPDATE: the first beta version has been released, and renamed to Bindable Behavior. Check it out at its bakery tutorial Bindable Behavior: control your model bindings.

It’s been some time since I’ve done any work on expects, and while enjoying the incredible set of cool features CakePHP 1.2 pre-beta is giving us all, I decided it was time to let expects meet 1.2. My new baby is called ExpectsBehavior. As its 1.1 predecessor, its main goal is to provide a wrapper for CakePHP’s unbindModel function, to let the developer specify what bindings (model relationships) he’s expecting right before a find. At the same time, I needed some new features to be added, some of them courtesy of the previous brain work Felix did on his very cool Containable behavior.

Continue Reading »

CakePHP 1.2 sexyness is mainly a result of its convention over configuration methodology. Theoretical discussions aside, conventions save us (developers) valuable time, and allow us to concentrate on where we should put our effort: business logic. Some conventions may go under the radar until you find what you think is a weird bug. Let’s see an example by building a simple action in a controller:

Continue Reading »

While enjoying the wonderful CakePHP live show (don’t despair, I will be on soon, adding some of my latin flavor to spice up phishy’s boring comments… just kidding , PhpNut made a remark that is worth listening to: CakePHP 1.2 allows you to override CakePHP’s defined tags. Yeah, I know, so did CakePHP 1.1, but now you can define your own base helper, from which all CakePHP helpers will inherit, and only override the tags you decide. That’s right, no more copying tags.ini.php to modify it. Just define what you need, and how you need it. Let’s see how.

Continue Reading »