Ibuildings has posted the fourth part of their "Programming Guidelines" series to their blog, sharing even more helpful hints and tips you can apply to your everyday development. In this new post author Matthias Noback talks about messaging in your application, not in output to the user but in the communication between parts of your system.

In the previous parts of this series we looked at how to get rid of complexity at the level of algorithms. After discussing the problem of nulls in your code, we looked at object lifecycles and how to encapsulate them properly. Now that we have objects that can be constructed and changed only in valid ways, we need to look at how they communicate with each other and how we can improve our code with regard to that aspect.

He then breaks up the rest of the article into a few sections:

• Object communication
• Message categories
• Command/Query Separation Principle
• Implementing commands
• Queries
• Documents
• Command query responsibility segregation
• Events

For each section a description of the topic is provided and a bit of sample code is included to help illustrate the change/functionality.

On the Ibuildings blog Matthias Noback has kicked off a series that wants to help PHP developers reduce the complexity of their applications. In part one he shares some general tips along with code snippets illustrating the change.

PHP is pretty much a freestyle programming language. It's dynamic and quite forgiving towards the programmer. As a PHP developer you therefore need a lot of discipline to get your code right. Over the years I've read many programming books and discussed code style with many fellow developers. I can't remember which rules come from which book or person, but this article (and the following ones) reflect what I see as some of the most helpful rules for delivering better code: code that is future-proof, because it can be read and understood quite well. Fellow developers can reason about it with certainty, quickly spot problems, and easily use it in other parts of a code base.

The rest of the article is broken up into several changes you can make to reduce complex code including:

• Reduce the number of branches in a function body
• Create small logical units
• Using single (variable) types
• Making expressions more readable

He ends this first post in the series with a mention of a few other books to read up on around the subject of "clean" and less complex code.

On DZone.com there's a recent post from Evert Pot talking about some guidelines for generating XML including a brief PHP example.

Over the last little while I've come across quite a few XML feed generators written in PHP, with varying degrees of 'correctness'. Even though generating XML should be very simple, there's still quite a bit of pitfalls I feel every PHP or (insert your language)-developer should know about.

His suggestions for better XML include:

• You are better off using an XML library (like xmlwriter)
• Understand Unicode
• CDATA is never a solution
• Be verbose
• Be careful with entities

Federico has posted a list of suggestions on things to look out for and to consider when you're refactoring your code.

Refactoring neither fixes bugs nor adds new functionality, though it might precede either activity. Rather it improves the understandability of the code and changes its internal structure and design, and removes dead code, to make it easier to comprehend, more maintainable and amenable to change. Refactoring is usually motivated by the difficulty of adding new functionality to a program or fixing a bug in it.

He's broken it out into a few topics with the suggestions underneath - things like looking at the "Big Picture", avoiding "Extreme Abstraction" and ensuring that your "Error Handling" is up to where it should be.