Abhinav Singh has a new post today looking at his method for preventing duplicate comments (similar to a method used on Wordpress blogs) using memcached.

In this blog post, I will put up some sample PHP code for Duplicate comment detection using Memcached without touching the databases. Towards the end, I will also discuss how the script can be modified for usage in any environment including forums and social networking websites.

His method uses a custom function (is_repetitive_comment) to create an md5 hash of the comment and username to check against the stored values on the memcached server. Code is included as is an explaination of how it all works together.

Jani Hartikainen has posted some of his opinions about code commenting in a response to this post from James Carr claiming that code comments on fresh code is a bad idea.

James puts it quite well: When you write comments, it would be much better idea to just talk with your coworkers about it. He uses "excuses" as an example - code which does something that you need to explain, or says something like "Here we do X but we should really do Y" While I partially agree - if you're not sure which approach you should use, or whether your approach is correct, talking with your coworkers is definitely a good idea.

Jani talks a bit about what he considers good and bad commenting - non-redundant, descriptive and sometimes difficult to remember to do correctly.

In a recent blog post from Johannes Schluter he proposes a "universal language" for documentation and code comments - English.

The argument for using only English is simple: Every developer should know at least basic English and using English helps when either outsourcing, opensourcing or reaching new markets. Now there are arguments against English, too, one is that not all developers are able of using English properly so reading and writing comments is more difficult for them - now you don't have to write long prosaic texts in comments, but still...

Comments on the post vary - some disagree and some say that this is how they're already doing things and it seems to be working out well.

Thanks to an initial article from Brandon Savage the topic of code commenting has been floating around the PHP community and several members have taken the opportunity to express a few thoughts of their own:

• Brandon Savage's blog entry kicking off the discussion by noting that not commenting the code is the "accrual of technical debt".
• In his blog post Marco Tabini mostly agrees with Brandon's comments with one difference - he suggests that correct code doesn't need comments.
• Dagfinn Reiersol takes a more pragmatic approach to the issue and wants to see the code before making a decision on whether the comments are needed or not.
• Benjamin Eberlei reinforces this refactoring idea and suggests staying away from ambiguous names and unclear code practices.
• Richard Thomas notes that comments have their place but they don't need to be taken to either extreme.
• Rob Allen's opinions on Benjamin Eberlei's thoughts
• Brandon Savage's reply to all of the criticism he's recieved over his initial post

Posted any thoughts or comments of your own on the subject and do see them here? Let us know!

Matthew Turland came across an interesting bug when working with the Cares Document Checker he's developing related to linting (running a syntax check) on a given PHP file.

While doing a lint check on a code block, a parse error was occurring on a line that contained a comment in the original source file. [...] Presumably what was happening was, even though the var_dump() call showed that actual newlines were being interpreted correctly, the r was also being interpreted rather than taken literally. This caused the comma following it to generate the error I was receiving.

An alternative to the method he was using, shell_exec, is proc_open, a function that opens a resource to handle a command execution and allows for more than just the "point and shoot" execution that things like shell_exec, or system.

Those looking to get into developing with CakePHP might want to get in on a book giveaway that Matt Curry is doing over on his blog.

I'm not sure if this is going to be frowned upon, but I'm giving away my review copy of CakePHP Application Development (reviewed here). I figure I don't have much use for it, so maybe someone else will benefit.

To be in the running, all you need to do is make a comment on the post by February 28th, 2009.

Davey Shafik has taken a look at return values and keeping them standard when handing them back from the results of a database query.

In #phpc we recently had a discussion about function return values; specifically from database queries. I'm going to go on a (admittedly, rather sturdy looking) limb and say this applies to pretty much any function that returns from a data resource, not just a database .

His personal preference is to return the results data if there's matching information but to return a false value if there is an error/not results were found. He includes a snippet of example code to show the structure he's talking about. Some of the comments on the post mention things like exception handling, other similar methods other developers use and the use of nulls.

DevShed finishes off another series with the last part of their look at making a blog app with the help of the CodeIgniter framework.

By using the framework, you'll be taking advantage of the MVC pattern to separate the application's logic from its visual presentation. This article will focus on the improving the appearance of the application's final details: the section concerned with receiving and displaying comments.

Starting with the full source from the previous parts of the series, they modify the view file for their blog's comments to ass come nice CSS and styling. The final page shows the entire code for the application (split out ino chuncks of code for each file).

Shawn Stratton has posted the first part of his series looking at "Code Readability". This part focuses on something that is often woefully forgotten by many developers - proper code commenting.

The simplicity of PHP can sometimes be overwhelming, with so many different ways and approaches to creating solutions for our problems we sometimes lose the ability to think past the current problem and into the future. [...] Today I'm going to try to address some quick ideas that most of you will already be familiar with, things that will aide in the general readability of code for future generations.

He looks at the difference between useful and non-useful comments: DocBlocks, putting them near decisions, listing array parameters, recording TODOs and how it can all help you generate API documentation quickly and easily.

Brandon Savage has his own response to the "comments are harmful" post over on the PHP in Action blog:

There's a lot of good advice, especially about writing clean code. But the article fails to address a good number of really critical details and to some degree misses the point of Eli's article.

He mentions these points - the value of writing comments before hand, the usefulness of descriptive comments, how they can be used as a todo pointing to future development and using them to share the knowledge and let other people in on what you're thinking.