In a post to his site Robert Basic makes an interesting suggestion about older codebases (legacy code) and how they should be handled. He suggests treating legacy code like 3rd party code.

Within the TDD community there’s an advice saying that we shouldn’t mock types we don’t own. I believe it is good advice and do my best to follow it. [...] This hidden advice is that we should create interfaces, clients, bridges, adapters between our application and the 3rd party code we use.

[...] What if we start looking at our legacy code the same way we look at the 3rd party code? This might be difficult to do, or even counterproductive, if the legacy code is in a maintenance-only mode, where we only fix bugs and tweak bits and pieces of it. But if we are writing new code that is (re)using legacy code, I believe we should look at legacy code the same way we look at 3rd party code, at least from the perspective of the new code.

He suggests that legacy code and new code should live in different parts of the application's structure and that, in order to use the legacy code, the new code should use interfaces to it rather than using it directly. He gives an example, showing the use of a User class from the legacy code and interfaces that could be used from the new code to work with it.

In his new post Mathias Verraes talks about the separation of concerns that, in his opinion, should exist between form, command and model and the validation of each.

Many of the frameworks I’ve worked with, promise to separate responsibilities with MVC. In practice, the end up coupling everything to everything. The forms are coupled to the models, and there’s a grand unified validation layer. This may be convenient at first, but it breaks down for larger systems, and creates headaches when having to support multiple clients. My approach is to clearly separate the validation for the form itself, from the Command validation and the model validation.

He talks about each of the different types in turn, starting with Commands. He suggests that the validation should happen in Value Objects in the Commands, validation rules in Models and some client-side validation (backed up by backend checking, of course) via Javascript or HTML5 fields.

In this new post to his site Jani Hartikainen suggests a few things you can do to help make your code "self-documenting" and more readable down the line (or for other developers).

Isn’t it fun to find a comment in code that’s completely out of place and useless? What if you could write fewer comments and still keep the code easy to understand? One of the primary ways to do this is making your code-self documenting. When code is self-documenting, it doesn’t need comments to explain what it does or its purpose, which is great for making the code easier to maintain. As a bonus, with fewer comments, it’s less likely they’ll be crap! In this article, I will show you several ways you can make your code document itself.

He breaks it up into a few different sections, each with some code examples and descriptions:

• Naming things
• Extract functions
• Introducing variables
• Defining class and module interfaces
• Code grouping

He finishes up with a few smaller tips including "don't use strange tricks" and "use named constants". What do you think makes for good self-documenting code? Share some of your own thoughts on the post.

In a bit of a ranting post on the WorkingSoftware.com.au blog Iain Dooley shares his opinion about most of the code he's seen, specifically related to templating engines: "Your templating engine sucks and everything you have ever written is spaghetti code (yes, you)".

Templating is a real hot button in the web development community. [...] The high horses that people usually get on are that all too familiar TLA MVC (Model/View/Controller) architecture and "separation of presentation and business logic". The poor pedestrians upon which they look down are those who have written "spaghetti code" - templates where presentation logic, markup, business logic, database access configuration and whatever else you might imagine are mixed up in the same file. Well, I've got some news for you: you're all wrong.

He points out that, with most of the major templating tools out there, there's most people still put some sort of business logic in their templates. Rarely will you find a "pure" template that only echoes out the data. He gives an example of a Mustache template with "empty" logic in it. He shares a new term his coined too: "Template Animation". This is the separation of the templating process as it is usually done and splitting it so that the output is a modified DOM resource rather than a static template.

He talks about some of the advantages of this approach and an example of its use in an example of a logged in user vs not logged in user as well as a brief discussion of Markdown/HAML.

The only thing that Template Animation advocates is that the technological barrier between the frontend and the backend is never crossed - that our templates are truly logic-less.

There's lots of comments on the post already - everything from support of the idea to systems that already implement this sort of idea to disagreeing opinions.

On PHPBuilder.com today there's a new article from Jason Gilmore introducing you to namespaces in PHP 5.3+ development. Namespaces make it simpler to separate out your code into functional pieces and help keep it organized.

The inclusion of namespace support within PHP 5.3 effectively brought the need for gripes and workarounds to a halt, however adoption of this exciting new feature has seemed surprisingly slow in the more than two years since its release. [...] The utility of this new feature is simply undeniable. Therefore I thought it would be worthwhile to offer a formal introduction to namespaces for the benefit of those PHP developers who haven't yet had the opportunity to investigate the topic.

He starts by introducing the concept of a "namespace" as a sort of container for your code, providing separation that prevents errors like the infamous "cannot redeclare class" issue. He includes examples of PHP's namespace syntax to split out two "Account" classes into two different sections. Using them is as easy as referring to them by their namespaced "path" or using something like the "use" keyword to reassign it to another name.

James Cohen has a quick post about what he calls a "poor man's parallelization" for working with batch jobs. It takes in parameters that tell it which set of jobs to run through when looping.

One common problem that I’ve seen time and time again with batch processing jobs (generally cronjobs) is that when they’re written they run quickly. Over time their workload grows until eventually it’s unacceptably slow. [...] To create a simple of way of separating the jobs in a consistent way we can use the modulus operator. It just calculates the remainder of two numbers. It’s a common arithmetic operator in almost all languages so this technique is pretty portable.

His proof-of-concept script takes in two parameters, the starting job number and the number to increment. His example is user IDs, but this type of script could be used for anything with an ID number. The script is then run from the command line with the parameters of your choosing.

In a new post to his blog Phil Sturgeon has posted about a patch he's created to give the pre-release CodeIgniter 2.0 version the ability to do some Modular Separation.

The fix was worked out a few hours after CodeIgniter 2.0 was released but I was hoping wiredesignz would incorporate and re-post. Sadly the man has other commitments to attend to, so I have released the patched version.

The patch includes two files - custom libraries to extend from for loading and routing in your CodeIgniter 2.0 application. For a better understanding of what this patch gives you, check out this thread on the CodeIgniter forums.

I just wanted to take a second and get some opinions from the readers out there around the job postings that this site has been doing for a while now. They've become more popular in the recent months and I'm concerned that they might be "interrupting the flow" of the news around them.

I wanted to get your thoughts on them and on an idea I'm considering - splitting them off into their own sub-site sort of thing. Right now, you can go to jobs.phpdeveloper.org and get to the latest job postings without the news items. Do you, opinionated readers, think that they should stay over there and not be included with the news? Or do you like having them all in one place, all in one feed?

Post your opinions in the comments - I'll be interested to see what you think...

UPDATE: Several people in the comments have mentioned it, but I wanted to point out one option on the RSS feed - the filtering I have built in. It's tag based, so if you didn't want the job posts in there, you could subscribe to this feed: http://phpdeveloper.org/feed/tag/-job-post. That filters out the job posts for you. It wouldn't be hard to translate this into another "jobless" feed.