Improve coder_format to re-format Drupal 6 core without wrong formattings

Task description

One of the things that has an great impact on Drupal's success is the widely adopted agreement on clean, sophisticated, and well-documented code. In an abstract view, we are not only using a language (PHP), but also using a dialect to articulate what we are doing. This means that core developers and most contrib module maintainers try to ensure that everyone else in the community understands all parts of the application and is able to fix or improve the code without language barriers. Without this solid ground, no one would be able to participate and contribute in the way the Drupal community members are doing. Many patches against Drupal core are holden back or even rejected because of unsuitable code.
To support developers in using the proper syntax, formatting, naming, and adhering to all other development guidelines for Drupal, the Code Review module has been developed, which outputs notices for all code that is considered wrong in terms of Drupal Coding Standards. While Coder does only a code review and leaves you with the results, there is also the coder_format script shipped with the Coder module, that strives to clean and re-format a whole file to adhere to Drupal's Coding Standards.
Cleaning the coding-style of a contributed module with coder_format is usually a 5-minute job. However, due to its current beta-state, there are situations where coder_format applies wrong formattings to some lines or all lines that follow some lines of complex syntax in a file.

• The goal of this GHOP task is to fix and improve the coder_format script, so that it can be applied recursively on Drupal 6 core without introducing wrong formattings (and fixing existing wrong formattings throughout Drupal core, of course).
• The result of this GHOP task must be a single patch file against coder_format.inc that is ready to be committed. To clarify in advance: not a patch against Drupal core -- Patch files against Drupal core are only needed to communicate the current results/errors of coder_format in this issue.
• To work on this task, you should have a local development environment, be able to run a PHP script from the command line, know how to access a CVS server, and how to checkout and create patches against a CVS module. You should have a (better good) visual diff tool to compare a resulting file with the original.
• You will have to deal with rather complex regular expressions, Drupal Coding Standards, reviewing of Drupal core (with and without Coder module), creating and applying patches, writing helpful inline documentation, and identifying wrong formattings.
• Coder_format can be run recursively on all files in a directory by invoking it with the --batch-replace argument. See inline documentation in coder_format.php for further information.

Resources

• First of all, inline documentation in the coder_format script.
• Drupal Coding Standards.
• Coder's issue queue which contains some very valuable information about proper coding-styles (use Advanced Search to find older issues).
• PHP's Tokenizer and Tokenizer Tokens which are used to identify PHP's syntax.
• http://www.regular-expressions.info/tutorial.html provides a great resource for regex-related questions and howto's, you will probably need.
• If you are working on Windows, you might additionally use the coder_format Windows installer, which I'll update with an improved version when this task has been claimed.

Primary contact

Daniel F. Kudwien (sun)
I'm pretty sure that fellow Drupallers like Doug, Stella, Core developers, subscribers of the Coding Standards Group and also developers in the #drupal and #drupal-ghop IRC channels will help out on any questions related to missing information about Drupal Coding Standards.

For the sake of completeness I'm adding a patch file against Drupal 6 core that is the result of coder_format. It's about 1,5 MB, so I needed to zip it. You will discover the first formatting error in drupal_urlencode() which leads to wrong indents in all following lines. Furthermore, the patch would be dramatically smaller, if there was a post-processor that removed any white-space from all lines containing only white-space (this is one of the needed improvements).