On the Ibuildings techPortal there's a new article from Johanna Cherry that takes a look at the full development life-cycle and points out that the actual coding of the application, that's the easy part.

Engineering software is so much more than coding. As a software engineer you take on several roles throughout the software development life cycle. Let us take a look at some key roles that developers play during the software development life cycle, some problems you can run into, and how to solve them.

She talks about the different roles of those involved in the parts of the process, the ones that make it all fit together like a well-oiled machine: the Planner, the Architect, the Coder, the Refactorer, the Tester and the Documentor. Each has their place in the process and to keep things running smoothly, they all need to be doing the best they can. Sometimes this also means that one person performs more than one role, depending on the situation and the need.

Brandon Savage has a suggestion for those interviewing developers for positions at their company - forget the coding test.

One thing I've noticed in hunting for a job recently is the number of companies that insist that you write them a code sample to spec. Not just any code sample, but a fully functional, complete application. This is absurd, for several reasons.

He suggests that, while submitting example code or taking a test as a part of the interview process can be a "first line" to be sure the person knows the language, they shouldn't be considered useful much beyond that. He likens it to people in other trades (like a plumber or electrician) to do their job before they can do their job...for you. Brandon suggests that the real key to a developer - how well they can learn - just can't be measured by a test like this.

Brandon Savage has posted a few suggestions about dealing with coding standards and how they can help improve the quality of your code via his refactoring of a bit of example code. This time the focus is on documentation.

One of the first things I look for when I check out code is how is the code organized? Is it laid out well? Is it coded to a particular standard? In our code sample, the first thing we should address is how does the code look. There are a number of suggestions I would make immediately.

His list includes four suggestions for/comments about different areas of his example code:

• There are no DocBlocks or clear coding standards
• Examining The Properties (comments of the class properties)
• Conditionals (changing inline to braced)
• Improving The Constructor (to make it more flexible)

On his code-diesel blog Sameer has posted a tutorial that introduces you to the PHP_CodeSniffer library and some simple examples of it in action.

A coding standard basically tells developers in what style they must write their code. If programmers work in a team than a coding standard ensures that each will be able to read the others code without any effort. [...] A tool which scans your source code and checks it against a standard would be quite a help. PHP_CodeSniffer is one such tool.

The PHP_CodeSniffer package allows you to check code (to "sniff" it) and ensure that it matches against a certain format. The tool doesn't do any testing outside of that, though - no unit testing or functionality checking.

Sameer includes a guide to getting the tool installed and using it to get the source files in a certain directory. He also points to a tutorial for developing your own coding standards.

Over on the Blue Parabola blog Matthew Turland recently posted a new tutorial on using the PHP_CodeSniffer PEAR package to check out how well your code adheres to the coding standard of your choice.

For the sake of consistency [on a client project], the development team had stuff with the coding standard used by the framework itself. However, evaluating the code manually is tedious and time-consuming. There's a solution to this type of problem: the PHP_CodeSniffer package from PEAR, which builds an infrastructure around tokenizers for PHP, CSS, and JavaScript and utilities to detect coding standard violations within code in any of those languages.

He includes an example token output (the codesniffer package is based on the Tokenizer) from a script and walks you through the initial setup of the package, how to create "sniffs" for the code you want to analyze and how to run them using the popular unit testing tool PHPUnit.

Stefan Priebsch recently posted about his struggles with creating a custom coding started with the PHP_CodeSniffer package:

In CodeSniffer, a coding standard is basically represented by an empty class that extends PHP_CodeSniffer_Standards_CodingStandard. I could not get the CodeSniffer to find my coding standard, though, and found the documentation lacking about where to put it, how to name it, and how to refer to it in the --standard switch.

After an email to Greg Sherwood (developer of the package) Stefan figured out his issue and has shared the solution in this post (step by step).

According to a new post on the tilllate blog today, "unit testing makes coding more fun":

"Unit testing is a test that validates that individual units of source code are working properly", that's what Wikipedia says about unit testing. That's general knowledge.

But what motivates me even more than the increased software quality is that it saves me development time. This sounds odd as you might believe that TDD means writing more code.

A real-life example is included (an internal invoicing system) with the steps they'd follow to test it normally via the browser (slow) or through the automated tests (fast!)

In a new blog post, Paul Jones looks at three aspects of coding style - line length, volume and density - and how different people have different assumptions as to what's "right".

When it comes to coding style, there are are various ideas about how you should write the individual lines of code. The usual argument is about "how long should a line of code be"? There's more to it than that, though. Developers should also take into account line volume ("number of lines") and line density ("instructions per line").

He mentions the PEAR style guide when talking about line length, reading code like and sentence in line volume/density and how the "shorter is better" concept can be pushed to its extreme limits taking code into the unreadable zone.

Raphael Stolt, in working on his component for the Zend Framework (based on the PHP_CodeSniffer PEAR package), pulled together all of the information Zend provides about their coding standards into one place.

Before jumping into the development of a Zend Framework coding standard for the PHP_CodeSniffer Pear package, I spent some time revisiting and compiling the available Zend Framework coding standards into a handy one-paged Pdf document.

You can download the file here or, if you want something a bit more "spread out", check out the coding standards on the Zend Framework website.

Spurred on by some previous benchmarks [pdf] from Ilia Alshanetsky, Joakim Nygard decided to run some his own benchmarks on the same sort of functionality.

There are numerous discussions in the blogosphere about whether to use echo versus print, if for() is faster than while(), etc. and though the gains are usually very small, I decided to add my thoughts to the debate. I found an article on optimization through coding habits in Ilia Alshanetsky's zend performance slides.

According to his results:

• Calling require_once() 10000 times in a for() loop with an empty file is 4x faster.
• With a simply autoload requiring a class and 10000 loops of new Foo() versus require_once('foo.php'); new Foo() shows that __autoload() is ~3.7 times faster.
• If a class method can be static, declare it static. Speed improvement is by a factor of 4.
• Avoid function calls within for() loop control blocks
• Always, always quote array keys.
• Get rid of 'harmless' error messages - they take time to generate and output.

I am not out to prove Ilia wrong - he knows PHP better than most - and for all I know, they could have optimized those very functions in PHP 5.2. [...] It would appear that there are improvements, albeit small, to achieve from minimal effort. Plus I was surprised by the discrepancies I found compared to Ilia's recommendations.