Stop throwing errors on well established D6 OO conventions

Hmm, is there a smart way how we can switch the standard of the sniffer just for views?

I don't think that modules should use the Views conventions, the should at least stick to the UpperCamelCase Drupal conventions for classes.

Methods are a problem if they are overridden (so the name can't be fixed), we could retrieve the class definition that belongs to the method and check if it extends another class beginning with "views_".

Sounds like a plan and a lot of work ;)

It is no shame if a module does not pass all code sniffer rules, because the coding standards change and evolve all the time. There will always be some legacy code in some modules that does not satisfy the newest standards, so I'm not convinced that we should implement and maintain exceptions. However, I know that Views is big - so I would say patches welcome.

Yea, a lot most of the views, ctools, features, and a lot of exported code don't actually follow the drupal conventions.

For now I think we should keep following the conventions and hopefully eventually everyone else will follow. :-/

So I'm trying to figure out if this is an actual documentation problem or a bug.

By the looks of it this might be a bug. I can't find anywhere in the coding standard implying that the class name must be camel case. If this does exist can anyone point me to it.

If not we probably should just remove this sniff.

Oh the OO docs are http://drupal.org/node/608152

We still need to figure out what to do here.

Who says a module needs to pass all drupalcs checks? Just because it can't be easily fixed it is still an error, right?

I'm not refusing to fix, I just won't do it myself. So again: patches welcome.

Oh, and of course all the old-style modules can be fixed:

// Backward compatibility class.
class views_object extends ViewsObject {
  function option_definition() {
    return parent::optionDefinition();
  }
  // repeat for all other non-camel case methods.
}

// Replaces views_object.
class ViewsObject {
  function optionDefinition() {
    ...
  }
}

Of course drupalcs will still throw errors for the backward compatibility class, but only on a limited part of the code base that is dedicated to backwards compatibility.

I'm happy to hear that drupalcs is used :)
I think the essential thing here is to find a consensus about what has which priority and also how to handle different use cases.

I would like to continue the work on drupalcs but unfortunately I'm absolutely buried in project work.
Assuming that klausi is in a similar situation it's essential to set priorities for the different tasks.
I think it's quite some effort to integrate a dependency aware sniff for class names - and if my assumption above applies whether klausi nor I do have the time to build this feature.
It's another thing if someone provides a patch, I'll happily take care about such one...

If providing a patch isn't a solution, how about using the configuration options of PHP_CodeSniffer? A possible solution could be to define the sniffs to execute - see Limiting Results to Specific Sniffs

I know right now some modules don't pass the sniff. But they don't all have to.

If excluding certain sniff is really important drupalcs can be configured to ignore that sniff.

I don't think we should write the code to support old coding standards. Even if old is last week ;-)

Also technically switching class names is a lot easier now in D7 because of the registry.

So essentially all the classes can be switch to use camelCase and all that would be required for any install would be to use a tool like Registry Rebuild to rebuild the registry.

Let's keep this open for further suggestions/ideas.

So is "Class" or "class" correct for Drupal? As I've just spent hours fighting ctools_plugin_get_class() and finally found that it's only detecting my class definition with the lower case variant.

EDIT: Created a new issue http://drupal.org/node/1513110

"class" is of course correct for the PHP language keyword.

I agree with ericduran that we shouldn't write code to support old standards. As much as it pains me to not see every test pass, I think that it is OK.

If this doesn't work for Views it is just an intellectual exercise.

@tim.plunkett: but all new code written for D6 or D7 should follow the current version of coding standards. From from http://drupal.org/coding-standards

Drupal coding standards are version-independent and "always-current". All new code should follow the current standards, regardless of (core) version. Existing code in older versions may be updated, but doesn't necessarily have to be.

Fixing title, as the OO coding standards were introduced even 1.5 years before Drupal 7 was released.

I do use Views and Ctools a lot and they are great modules. Still, their coding standards are wrong in this regard. Untill somebody comes up with a patch to work around views and ctools in ValidFunctionNameSniff and ValidClassNameSniff here is the additional config for ruleset.xml to run drupalcs without those sniffs on your views/ctools code:

 <rule ref="Drupal.NamingConventions.ValidClassName.StartWithCaptial">
  <severity>0</severity>
 </rule>
 <rule ref="Drupal.NamingConventions.ValidClassName.NoUnderscores">
  <severity>0</severity>
 </rule>
 <rule ref="Drupal.NamingConventions.ValidFunctionName.ScopeNotLowerCamel">
  <severity>0</severity>
 </rule>
 <rule ref="Drupal.NamingConventions.ValidFunctionName.NotLowerCamel">
  <severity>0</severity>
 </rule>