Category Archives: codesniffer

codesniffer, open source, PHP, PHPCompatibility

Code quality tool PHP_CodeSniffer has a new maintainer but needs corporate support

Leave a comment

Introduction

In a recent and significant development for the PHP_CodeSniffer project, a change in maintainership has taken place, with Juliette Reinders Folmer now at the helm. This transition has not only brought fresh energy and vision to the project but also signals a call to action for companies and organizations to actively support its ongoing development. As PHP_CodeSniffer plays a crucial role in maintaining code quality and standards within the PHP community, corporate sponsorship is now more crucial than ever.

New Leadership and Repository Migration

The PHP_CodeSniffer project, originally developed by Greg Sherwood of Squiz Labs, has undergone a notable shift in leadership. Juliette Reinders Folmer was the main contributor for the last year and, with Greg having insufficient time to continue leading the project, it was decided to migrate the project to a new repository, signaling a new chapter in its development. The move is aimed at fostering a more collaborative and community-driven approach to ensure the tool’s continued evolution and adaptability to the ever-changing landscape of PHP development.

Juliette Reinders Folmer, a well-respected figure in the PHP community, brings a wealth of experience and a fresh perspective to the project. Her commitment to maintaining and enhancing PHP_CodeSniffer aligns with the community’s expectations and highlights a dedication to its continued success. Juliette is also the lead developer for other quality assurance tools like PHPCompatibility and PHPCSUtils.

The Importance of Corporate Sponsorship

With the PHP_CodeSniffer project been transitioned in the coming days, the need for financial support from the community, especially corporate entities, is paramount. Open source projects like PHP_CodeSniffer rely on contributions, both in terms of code and financial backing, to thrive and remain sustainable over the long term.
Corporate sponsorship ensures that the project can dedicate resources, including developer time, to addressing issues, implementing new features, and maintaining compatibility with the latest PHP releases. It also allows for the organization of events, workshops, and community outreach initiatives, fostering a stronger and more engaged user base.

How Companies Can Contribute

To support the ongoing development and maintenance of PHP_CodeSniffer, companies are encouraged to sign up for sponsorship through the project’s Open Collective page (https://opencollective.com/php_codesniffer). Open Collective provides a transparent and accountable platform for managing funds, and it allows sponsors to track how their contributions are utilized.

By sponsoring PHP_CodeSniffer, companies not only demonstrate their commitment to the PHP community but also ensure that the tools they rely on for code quality continue to evolve and meet the demands of modern PHP development.

A call to action for developers

If you’re a developer reading this and your project relies on PHP_CodeSniffer or any of the dependant projects (such as PHPCompatiblity or PHPCSUtils) in its quality assurance process, consider what contributions mean :

  • Receiving updates to PHP_CodeSniffer to handle new syntax that is added to PHP
  • Receiving updates to individuals sniffs in all standards to be able to handle new PHP syntax
  • Improving contributor friendliness of projects
  • Reviewing contributions and coaching contributors
  • Coaching potential candidates for joining the maintainer pool, ensuring the project survives long-term

If you value the quality of your code, push your project manager, product owner, CTO or CEO to contribute to the project, given they’re saving not just on valuable development time, but on bug-fixing, just by using the project.

codesniffer, PHP, PHPCompatibility

PHPCompatibility update

11 Comments

Update (Nov 3, 2013) : changed the parameters to reflect the new changes in PHP_CodeSniffer

Just a quick post about the updates made to PHPCompatibility.

I did a talk on PHP 5.4/5.5 at Zendcon, not just about what’s new and why you should upgrade, but also about the way PHPCompatibility can ease the pain. I received very good feedback, as well as very interesting questions. As a result, I added a feature I’ve wanted to add for a long time : the option to specify which PHP version to check for.

Here’s the caveat : it requires a change to PHP_CodeSniffer. I’m hoping that change will be accepted soon. From that point onwards, if you have the latest PHP_CodeSniffer (you might want to get it from Github).

So then you will be able to do :

phpcs --standard=PHPCompatibility --runtime-set testVersion 5.4 <path-of-your-php-files>

You can also test for backwards compatibility of your code by specifying versions like 5.2, which causes it to check whether you’re using functions or keywords not known to this older version. Quite nice if you’re coding on PHP 5.5, but your system engineer tells you half way through the project the project will have to be deployed on 5.2.

Important note : if you want to test backwards compatibility, it’s best to run on the latest PHP version available (5.5 right now), for the simple reason that if you have, for example, the keyword ‘yield’ in your code, PHP_CodeSniffer can only recognize it when you’re running PHP 5.5. It can only tell you it’s not available in previous versions if it actually knows what it is.

Expect more compatibility tools soon, as I have some more ideas, such as how to automatically figure out whether and where you’re still relying on register_globals and magic quotes 😉

codesniffer, open source, PHP

PHP 5.4 compatibility checks using PHP_CodeSniffer

34 Comments

Update (27 Nov) : Support for PHP 5.5alpha is included.

For those of you who are new to this concept, check my blog post from a while ago. It will explain the basic concept of using PHP_CodeSniffer to automate compatibility checks. But don’t use the download links, because they point to the old (PHP 5.3) version !

What’s new ?

Quite a few things have changed in this new release :

  • There’s no version specific release anymore. The previous codesniffer standard was called PHP53Compatibility, but it seemed quite stupid to make a new standard for every PHP version out there, especially since that would keep certain people from upgrading to the latest major PHP version. So the new PHPCompatibility standard works for 5.0 – 5.4
  • But since some people simply can’t upgrade to the latest version, I added version information to all the checks. For example : the deprecated  function checker will now tell you that session_register() is deprecated since PHP 5.3 and removed since PHP 5.4 – if you’re running 5.2 and want to move to 5.3, at least you know right away that you’ll have to fix that problem, because otherwise you can’t ever upgrade to 5.4. This version check is available on deprecated/removed function, deprecated/removed php.ini directives and deprecated/removed extensions.
  • Default timezone check has been added : since PHP 5.4, you need to have a default timezone set or PHP will complain. This is ofcourse only useful if you run the tests on a system with identical settings as your production environment.
  • A check for the removed functionality on break and continue was added. (Using a variable or function call as a parameter on break and continue is no longer allowed.)
  • 2 algorithms were removed in the hash extension, so there’s a check for that as well

Where to get it

2 options :

  • Using git : run this in your PHP_CodeSniffer/Standards directory :
    ~ > git clone git://github.com/wimg/PHPCompat_CodeSniffer.git PHPCompatibility
  • Downloading a zip : download here and unzip the file in PHP_CodeSniffer/Standards/PHPCompatibility

How to run it

Start PHP_CodeSniffer like this :
phpcs --standard=PHPCompatibility

Enjoy !

As always, any feedback (or patches on Github) welcome !

codesniffer, open source, PHP

Automated PHP 5.3 compatibility testing for your (old) code

29 Comments

Update (Mar 5, 2012) : check here for the latest version, supporting PHP 5.4 as well.

Update (Dec 22, 2010) : code has seen some minor modifications to ensure compatibility with the latest PHP_CodeSniffer release (1.3.0RC1) – thanks to Sebastian Bergmann. Also updated the instructions below.

Note (Dec 22, 2010) : this compatibility test will also test all testable cases for 5.0, 5.1 and 5.2

So you or your team has built anywhere between 5 and 500 projects in PHP 4, 5.1 and 5.2 over the past 5 years. And now PHP 5.3 is there, offering a lot of very interesting features, including namespace support, late static binding (finally !), closures, nested exceptions and a bunch more (see the new feature list).

So naturally, you’d like to upgrade. But doing so might break some old code. Why ? Because of some backward incompatibilities :

  • New reserved keywords (goto, namespace)
  • Deprecated functions that will throw an error (the brand new E_DEPRECATED error in fact !)
  • Call-by-value on functions with by-reference parameters will now raise a fatal error
  • and again… many more (see the list)

So how do you ensure your code is PHP 5.3 ready ? Well, there’s a few options.

Option 1 : run your unit tests

You just knew I was going to say that, didn’t you ? Yes, unit tests are still the best way to test the inner working of your code. Although even 100% code coverage will not guarantee a bugfree system ofcourse (some bugs are by design, others by neglect, others…)

Option 2 : test your application

Seems logical, doesn’t it ? Install PHP 5.3 on a separate environment or on your test environment and test the entire application. Ofcourse there are issues for some :

  • Old projects often don’t have any budget allocated for this kind of tedious testing
  • Testing an old project is not easy if the original developers aren’t around anymore… so the testing is best done by the actual user… but you don’t want users to see how their application breaks “because of old code”
  • If you have a lot of projects, testing them one-by-one could take a while… maybe 5.4 will be out by then :p

Option 3 : automate your PHP 5.x compatibility tests

Although the first 2 options are really required to ensure your code is PHP 5.3 ready, using automated tests can get you a long way in detecting deprecated functions, unsupported extensions, etc.

Because I’m in charge of moving about 50 projects to PHP 5.3 in the next few weeks/months, I decided to make at least part of this tedious task a little smoother (and faster).

To use the system, all you need is PHP_CodeSniffer and a new sniff standard I created. You will see errors and warnings popping up if part of the code is not PHP 5.3 compatible.

What’s being tested

  • Deprecated functions
  • Deprecated php.ini directives set via ini_set() or retrieved via ini_get()
  • Deprecated assigning of the return value of new() by reference
  • Prohibited names in function name, class name, namespace name and constant name
  • Magic methods can no longer be private, protected or static
  • Removed, unsupported or deprecated extensions
  • All of the above is being tested for PHP 5.0, 5.1, 5.2 and 5.3 compatibility issues

How to download and install

~ > git clone git://github.com/wimg/PHP53Compat_CodeSniffer.git PHP53Compatibility

  • Copy the PHP53Compatibility directory to {your pear path}/PHP/CodeSniffer/Standards

How to run

Start PHP_CodeSniffer like this :

phpcs --standard=PHP53Compatibility

Sample output

FILE: C:\temp\bla.php
--------------------------------------------------------------------------------

FOUND 15 ERROR(S) AND 2 WARNING(S) AFFECTING 12 LINE(S)
--------------------------------------------------------------------------------

4 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'goto' (since version 5.3)
6 | ERROR | Extension 'dbase' is not available in PHP 5.3 anymore
12 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'const' (since version all)
12 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'const' (since version all)
12 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'const' (since version all)
12 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'const' (since version all)
12 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'const' (since version all)
14 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'do' (since version all)
16 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'goto' (since version 5.3)
18 | ERROR | Function name, class name, namespace name or constant name can
| | not be reserved keyword 'namespace' (since version 5.3)
20 | ERROR | Assigning the return value of new by reference is deprecated in
| | PHP 5.3
31 | ERROR | Magic methods must be public (since PHP 5.3) !
31 | ERROR | Magic methods can not be static (since PHP 5.3) !
36 | ERROR | Extension 'mhash' is not available in PHP 5.3 - use the 'hash'
| | extension instead
42 | ERROR | Extension 'msql' is not available in PHP 5.3 anymore
48 | WARNING | The use of function magic_quotes_runtime() is discouraged
50 | WARNING | The use of ini directive 'safe_mode' is discouraged
--------------------------------------------------------------------------------

Some important notes about the system

  • The system checks for deprecated functions, new reserved keywords and other changes from PHP 5.0 to 5.3. However, it doesn’t check for every incompatibility, only a subset that was easily testable using PHP_CodeSniffer. So you still need to check your application manually to see if it runs properly. However, at least part of the job has been made a little easier.
  • You need to run the tests on a system with PHP 5.3 installed (sounds logical, but seemed like a good idea to mention it…)
  • The tests were written on a sunny afternoon with lots of interruptions, so they’re all but perfect. Please let me know if you find bugs, things missing or just want to flame me 😉

As always, no guarantees that it will do the job… but if you feel it’s of use to you, let me know in the comments !