Google Groups

Re: [silverstripe-dev] Re: SilverStripe Coding Conventions and PHPCodesniffer

Stig Lindqvist Sep 23, 2012 3:01 PM
Posted in group: SilverStripe Core Development

On Saturday, 22 September 2012 10:43:01 UTC+12, Sam Minnée wrote:
If we can add a whitelist of any incompatible method names, then we can still include the test and use to ensure that no new names are introduced. Alternatively, we could only allow incompatible method names if they are @deprecated, but I don't know how hard that is with the sniffing framework.

Ages back I did some custom sniffs to check for method names. Since a lot of method naming depends on the usage it's a bit hard to fully automate it. Put it's possible to check that static methods are lower case named. Currently the ruleset doesn't check for it.

Checking for annotations, tricky, but it's as it's possible to make our own sniffs it should be possible. Would probably take some effort of getting it going.

Again: our goal should be to have an automated check for every potential objection to a pull request that we can push off human reviewers' plates, so I also support getting this into the CI build.

It might also safe guard against common code smells such as cyclomatic complexity, god methods etc. 

On 21/09/2012, at 8:31 PM, Ingo Schommer <> wrote:

FREAKING AWESOME! I remember you showing me this when you were
still in Sweden, and I've had a todo item for "port Stig's codesniffer to new conventions" ever since heh.

We could hook into Travis, which would be the most visible automation.
But from what I can tell, we can't run the sniffer against diffs.
So for now, even if your changes are adhereing to the conventions,
but the file you changed is not, the sniffer will fail, right?

If that's the case, we need to fix up core first, which won't be a trivial exercise.
There's a project which might help with the basic bits:
Its written by the Symfony lead dev, and applied to Symfony code, so should be fairly solid.

That won't fix stuff like wrong class/method naming conventions of course,
of which we have plenty - those will be a slow deprecation cycle to fix. 
For any automation, we'd need to suppress those errors to keep the output meaningful.
Overall, I think the most useful mid-term application would be a diff of the sniffer error output,
which should be doable in CI (at least for TeamCity, not sure for Travis in terms of persistence).


You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at