In response to a comment he saw on Twitter about comments in code, Matthias Noback has written up a post with some of his own thoughts.

Recently I read a comment on Twitter by Nikola Poša. [...] He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

Matthias starts with the suggestion that, when correctly written, code shouldn't need comments to be clear about what's happening. He encourages the use of the "refactor for clarity" method to remove comments and make the code more clear. He finishes the post by breaking down the types of comments (explanatory, todo and "wtf"), what they are/examples and in what situations they can be useful for.

With the first stable release of PHP 5.4 not too far off, it's important to understand the new features it offers and how to use them effectively. In this new post to DZone.com Giorgio Sironi shows how to "write clean code" with these new features, including a few snippets of code to illustrate.

After seven release candidates, it's clear PHP 5.4 is coming: as always the improvements from the previous minor version are many. [...] Let's look at the new features and score them on two metrics: usefulness, and potential for abuse. I'll try to avoid discussing non-language related matters.

He starts by pointing out some of the "gotchas" that can happen with traits (like errors thrown when more than one method is named the same and that they are a separate hierarchy), the short syntax and dereferencing support for arrays, closure binding, upload progress and more. For each of them he gives two measurements - the usefulness of the feature and the potential for abuse.

On the php|architect site today there's an opinion piece from Marco Tabini with his thoughts on why software fails - not why the project itself fails, but why the software fails to be useful.

This is a much more common problem than engineers and architects are willing to admit. Far too often I see someone in charge of writing a piece software worry about how a product works without paying so much as a passing thought to whether it actually works the way people expect it to. The truth is that we are, by and large, stuck in a reality where software somehow equates with automation.

He goes on to talk about how easy it is for us, as developers, to forge head with features and software that may not be useful to the masses. We worry more about solving a problem that may or may not actually be there. He illustrates with the example of a to-do list, providing the automation to make list tracking easier, but no guidance of how the user can make use of it effectively.