unset($var1);
unset($var2);
unset($var3);

But as you can see from the PHP doc page of unset() this method takes optional parameter count.

void unset(mixed $var [, mixed $var [, mixed $...]])

So perhaps a better solution can be:

unset($var1, $var2, $var3);

It’s at least single lined!

What happens if you have to write a getUserArticles method? Where would you put it? Whether this will be the User model or the Article model?

Although technically you can put it in both models my advice is to look at the SQL query. If the FROM clause is containing the user table – than put the method in the User model, but here you’d have something like:

SELECT * FROM Article WHERE user_id = 1

I’d prefer to place it in the Article model!

 true,
            'lifetime' => 60
        );

        $backendOptions  = array(
            'cache_dir' => realpath(APPLICATION_PATH . '/../cache')
        );

        $cache = Zend_Cache::factory('Core',
                                     'File',
                                     $frontendOptions,
                                     $backendOptions);

        Zend_Registry::set('cache', $cache);
    }
}

Than add it as a front controller plugin:

// cache plugin
$frontController->registerPlugin(new CacheInit());

$mailTransport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
    'auth'     => 'login',
    'username' => 'xxxxxx@gmail.com',
    'password' => 'passxxxxx',
    'port'     => '587',
    'ssl'      => 'tls',
));
Zend_Mail::setDefaultTransport($mailTransport);

i++; // we increment i with one

That’s a shame! This doesn’t tell you anything, and what will happen if sometime later somebody sits in front of that code? He’d be amazed!

How To

In fact the task is not to determine what are the bad parts of not commenting the code, but how to overcome this. How to write comments. Here are some basic advices.

1. Think about the other developers

First of all the most important thing is to write comments with other programmers in mind. They should understand the logic of your code from your comments and not from the code itself.

2. Write in English

Even you’re not a native English speaker, and you English is not so good, it’s a must to write in English. This is really important when you work for a open source project when always there’s a big community around the project, you cannot be sure that everybody understands your language.

I know that this is difficult – also for me the English is not my native language, but that’s really a must. Once you start doing it, you’ll see that it’s not so difficult.

3. Comment the methods as a black box

Don’t write in a method comment what technique is used to achieve the result. It’s good to describe what the method does, not how it does it.

Bad example:

/**
 * returns $a + $b
 */
public function sum($a, $b) 
{
    return $a + $b;
}

Better:

/**
 * Returns the sum of two numbers
 * 
 * @param number $a
 * @param number $b
 * @returns number $a + $b
 */
public function sum($a, $b)
{
    return $a + $b;
}

4. Comment the logic, not the technical solution

When there’s a loop or a statement it’s useless to describe that this is a loop or statement, isn’t it? A better approach is to describe in a comment why you needed to implement this logic in such way.

Wrong:

...
$arr = array();
$i = 0;

// in a while loop we
// initialize every element with 0
while ($i < 100) {
    $arr[$i++] = 0; 
}
...

Better:

...
$arr = array();
$i = 0;

// we initialize an array of 0s
// to store the sorted elements
// on the first pass... etc, etc.
while ($i < 100) {
    $arr[$i++] = 0; 
}
...

Conclusion

In fact the most important thing is to write comments with other developers in mind. Tell the future developer of that code what's in the code, and pray for mercy

1. Write a human readable source file

In fact you can do this even without Zend_Translate. Image you’ve an ini file with some pairs like:

lblMyLabel = "My Label"

Nobody says this cannot be “more” human readable – like so:

My Label = "My Label"

Than you can support several files i.e. en.ini, de.ini, etc. where you can translate this label. The problem is that once you read the ini file you’ve to deal with those white spaces into the labels, while with Zend_Translate you can simply call them with:

$translate->_("My Label");

2. Default values for missing labels

Zend_Translate forces you to define a source file. Which is really great, because you always have a default value. Assuming that you don’t have a specific label translated in one of the ini files, you’ll get the default value from the source file, and defining source and other files is as easy as:

// en.ini
My Label = "My Label"

// de.ini
...

// while the locale is de_DE you'll have 
// the default value returned
$translate->_("My Label"); // will return My Label from the en.ini

3. Locales

It’s really great that you can directly setup a locale for this module. Thus you have more flexibility when switching between languages and you can benefit from the power of the framework when reading some browser specific locales. Here’s some code:

$translate = new Zend_Translate('ini', 'en.ini', 'en');
$translate->addTranslation('de.ini', 'de');

// than when you setup the translation locale
$translate->setLocale('en');

4. Cache

One of the greatest things about Zend_Translate is the native support of cache. It’s so cool! Actually the labels of a large web system are pretty static and don’t change every day. In other hand in large scale systems there are lots of labels, and the load time will be faster with cache.

$frontendOptions = array('lifetime' => 600, 'automatic_serialization' => true);
$backendOptions  = array('cache_dir' => 'path_to_cache_dir');

$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);

Zend_Translate::setCache($cache);

It’s a great advantage to use Zend_Translate after all this. Actually I have finished projects without any use of it, but I really can’t imagine how I’ll work now without it!

Here’s some code:

public function jsonAction()
{
	$data = array(3,4,'test', 'my-name' => 3,4);

	echo Zend_Json::encode($data);

	$this->_helper->viewRenderer->setNoRender(true);
	$this->view->layout()->disableLayout();
}

and the result is:

{"0":3,"1":4,"2":"test","my-name":3,"3":4}

Note that all integers are printed without double quotes – which saves some space!

The job can be done with a event’s which check. Let me show you some JavaScript/jQuery code:

$('.selector').click(function(e) {
	console.log(e.which);	
});

Note that this can be checked under Firefox and/or Safari like browsers which support the console object. This will give you the idea which key is pressed in a number value. The Enter is usually 13!
If you don’t have such browser, you can replace that code with something like:

$('.selector').click(function(e) {
	alert(e.which);	
});

My advice is to rely on a defined standard. I personally use the Zend Framework’s coding style.

So how to format the code? The first way is on the same line:

$myArray = array('key1' => 'value1',
		 'key2' => 'value2');

And the other, perhaps more clear way is to place the associative pairs on a new line:

$myArray = array(
	'key1' => 'value1',
	'key2' => 'value2',
);

Note that in the second example there’s a comma after the second pair. This is correct PHP syntax and is strongly encouraged!

It’s up to you which way to take. However it mainly depends on the case, but please use standards.

You’ve probably seen that you can track the server response headers with Firebug – a wonderful extension to Firefox.

But have you ever asked yourself how to change a response header with Zend Framework.

header()

Typically this is done with the built in PHP function header, where you can setup the header the page must return, but how to make it with Zend Framework?

It’s pretty simple of course, it’s Zend Framework in fact. To be more precise I’ll post a snippet:

$response = $this->getResponse();
$response->setHeader('content-type', 'application/x-javascript; charset=utf-8');
$response->sendResponse();