Posts by Tag "CodeSniffer"

I dived into the code of my new favorite IDE Netbeans these last days and came up with an extension module, which adds PHP CodeSniffer Support on a per file basis to make my life much easier. It shows warnings and errors as annotations to the Editor and marks the affected lines in yellow and red.

My Java skills being very bad, it will only work on Linux currently, since the PHP Code Sniffer "binary" is hardcoded into the Java Source code. You have to create a "/usr/bin/phpcs2" executable, which is a wrapper that looks like:

With Manuals extensions (see the comments) the module now works without the wrapper script. It might even work under Windows now. Yet now the Zend Coding standard is enforced though. I am working on making that one configurable next.

You can install the NBM module install file from the GitHub repository into Netbeans and it "should" work then.

I hope to get more familiar with Netbeans in the future to add some more PHP tools and enhance Code Sniffer support.

These last days I had fun with Padraic Bradys MutateMe project. It dynamically changes your code (using PECL Runkit extension) and checks weather your test cases fetch the errors occurring from changing the source code. This is a great addition to having a test suite, because it finds all the problematic test cases, that try to do too much and fail to cover the code correctly.

I have also contributed to the MutateMe project already and this was only possible due to Git and GitHub, which makes contributing to any project easy like writing a hello world example in a random programing language. As such I have to agree with Padraic: I love Git, too! He already integrated my and Sebastians changes back into the master and we didn't have to focus on merging, communication and integration alot.

My PUMA project is also hosted on GitHub (although nobody has looked into that yet), but I am beginning to write a complete Runner now that calls all three components PHPUnit, PDepend and CodeSniffer at once and directly processes the results. When this is done, I will pack it all up as a PEAR package for anyone to test out.

Some days ago i posted about the PHP Unittest and Metrics Aggregator tool that i have written on (and which I have dubbed PUMA). Discussing it with people I came to the conclusion that the approach using ezcMvcTools is quite problematic that it forces to use this application, although the reporting and the application are quite separate. This is not against ezcMvcTools: I love it, its just the wrong type of support.

I began to split up the aggregator into some sort of importing-exporting tool. You can specify library-, test- and output-directory of your application and it will use the tools at hand (PHPUnit, PDepend and CodeSniffer currently) to generate their XML formatted reports. It then parses those XML outputted files and combines their result to give a consistent view on your application.

The Import-To-Output generator uses a three-step approach. An importer emits signals to report observers, which will then hand over their collected data to specific html pages that are then generated to the disc. This is a very flexible approach that allows anyone to extend and re-use the tool to generate project metrics, unittest overview and other interesting details on your application.

Have a look at the tool on Github and play with it. I would really like to hear your thoughts.