Christian Mackeprang has a post to his site with some ideas about reducing the "cognitive load" of your code - basically making it easier to follow, read and understand.

Low bug count, good performance, easy modification. Good code is high-impact, and is perhaps the main reason behind the existence of the proverbial 10x developer. And yet, despite it’s importance, it eludes new developers. Literature on the subject usually amounts to disconnected collections of tips. How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!

I believe it’s possible to construct a simple mental framework that can be used with any language or library and which will lead to good quality code by default. There are five main concepts I will talk about here. Keep them in mind and writing good code should be a breeze.

His tips center around concepts like:

• following coding standards for consistency
• clarification through modularization
• overall readability and application structure
• good naming on variables and methods/functions

For each topic he gives a brief summary and some example code, usually showing what not to do and a solution or two to help with the clarification.

Joshua Thjissen has a post on his site that wants to help you understand the basics of Symfony2 forms including how to build them, extend them and the modules they're made up of.

To actually use Symfony2 forms, all you need to do is read some documentation, a few blog posts and you’ll be up and running in a couple of minutes. Understanding Symfony2 forms however, is a whole different ballgame. In order to understand a seemingly simple process of “adding fields to a form”, we must understand a lot of the basic foundation of the Symfony2 Form component. In these blog posts, I’ll try and give some more insights on this foundation.

He starts by explaining the three main steps in the typical form lifecycle: building the form itself, populating and validating data and rendering the form to the waiting user. He then gets into some of the basics of using forms and the types of objects that make them up. He includes examples of creating a simple form, the YAML configuration it compiles to and the functions used to build, render and set options on the form. He finishes up the post looking at form inheritance, extending the form types and where the "ResolvedFormType" comes in to play.

The Dzone.com site has a recently posted tutorial helping you understand the php.ini, the main configuration file PHP uses to set up its own internal features and settings.

our php.ini file provides a considerable amount of power over the behavior of your PHP application ecosystem. Let’s jump into some of the most common declaratives and discuss how they impact your application performance and behavior. I won’t go into an explanation of each setting that is available, but I’ll cover the fundamental options that you should be aware of. Please keep in mind that changing any of the settings on in your php.ini can and may very well change the behavior of your application, whether positive or unfavorable. Please use caution when adjusting your settings, consult with your team, do your research, understand the implications, and, of course, test, test, and test again before deploying anything into production!

He starts with a brief introduction to what the php.ini file is and how you can use the phpinfo function to find the current settings in HTML form (on the command line it's "php -i"). He then goes through and covers some of the basics from the standpoint of security, memory handling and some general settings.

Matthew Setter has posted five reasons why he thinks that making a coding standard is an essential part of your development process. He suggests that "pain avoidance" is one of the key factors, both for new members of the team and for those maintaining it in the future.

Whenever you’re working on a project, are you consistent? Are you consistent in your coding style, consistent in your documenting, consistent in your database naming conventions? Better yet, do you and your team have a coding standard which you consistently adhere to? If you don’t, you’re buying yourself and others a world of pain – which is painlessly simple to avoid. Today I’m banging the drum, shouting from the street corner, calling from the cathedral spire, imploring you to do one thing, above all else – pick a coding standard and then BE CONSISTENT!

His five reasons for implementing (and effectively using) a coding standard are:

• Poor, Inconsistent Code - Causes You Pain
• Your Code is Easier to Read
• Your Code is Easier to Understand
• Your Code is Easier to Maintain
• Your Code is Easier to Collaborate on

Check out the post for summaries of each point.

David Parra has a suggestion for PHP developers out there - it might be beneficial to learn some C so you know what's going on.

I think most of the people using PHP wonder from time to time about particular behavior of the language. [...] But lately I stumbled over a nice one. It looked like a bug in PHP, but turns out to be an interesting, curious, part of the C-language.

He gives an example of a case where an error message (as a result of E_ALL error reporting) shows evaluation of certain variables in a different order than anticipated. As it turns out, the difference was in the order of the parameters in the C code of PHP (different on SPARC versus x86 systems).

In this new post from the PHP in Action blog, they comment on Eli White's comments on commenting.

There is too much old advice in PHP. A recent case comes from the PHP Advent calendar. Eli White is a strong believer in commenting code, including inline comments inside functions. Unfortunately, he's at least 10 years too late. This used to be good advice, but not any more. Up to a point, he's right.

They propose a better way - refactoring code so that its as easy to read as possible, reducing the need for extensive commenting. They illustrate with a rework from the Zend Framework function, changing up the method names to better reflect the action inside (rather than the current "doUpdate").

The CakePHP podcast, "The Show" has posted it's latest episode - a spotlight on the FormHelper component of the framework:

Nate Abele and Larry Masters join me to discuss the new FormHelper feature in CakePHP 1.2. This time we manage to stay on topic and sober. Join us for an archived hour of form developing goodness.

You can either subscribe to their normal feed, their iTunes feed or you can just grab the show directly from the site to enjoy the episode.

The CakePHP podcast, "The Show" has posted it's latest episode - a spotlight on the FormHelper component of the framework:

Nate Abele and Larry Masters join me to discuss the new FormHelper feature in CakePHP 1.2. This time we manage to stay on topic and sober. Join us for an archived hour of form developing goodness.

You can either subscribe to their normal feed, their iTunes feed or you can just grab the show directly from the site to enjoy the episode.

A few days back there was a post on the "The Codist" blog about why the author would never quite understand the appeal of PHP to the masses and some of his thoughts behind it. Well, there was such an outcry and response to his comments that he's written up another post on what he learned from comments made.

Clearly I touched a nerve. However I did learn a lot of things that you don't read in a quickly tutorial on PHP. The whole point of writing something is to get feedback, positive or negative, and hopefully learn from it.

He admits that his experience with PHP and its developers has been limited, so his perspective might have been thrown off a bit. He still holds to one thing from the previous article, though - that PHP just isn't for him.

A few days back there was a post on the "The Codist" blog about why the author would never quite understand the appeal of PHP to the masses and some of his thoughts behind it. Well, there was such an outcry and response to his comments that he's written up another post on what he learned from comments made.

Clearly I touched a nerve. However I did learn a lot of things that you don't read in a quickly tutorial on PHP. The whole point of writing something is to get feedback, positive or negative, and hopefully learn from it.

He admits that his experience with PHP and its developers has been limited, so his perspective might have been thrown off a bit. He still holds to one thing from the previous article, though - that PHP just isn't for him.