Now that OOP is stealthily making its way into Drupal, we need to bolster the coding standards a bit. Here's what it currently says at http://drupal.org/coding-standards :

Class Names: Though classes are rarely used in Drupal, their name should use "studlyCaps." For example:

$type = new stdClass();

First of all, from my brief survey of D7, this seems incorrect. Class names actually use CamelCase. That is, class names begin with a capital letter and are written without underscores, with each new word being uppercased.

Secondly, the example does not tell us anything. The variable, $type, is lowercase so clearly the case reference is not referring to variable naming. And stdClass, as an internal reserved Zend class name, is an exception to the naming of classes found in practice, such as BlogTestCase.

Next in the crosshairs is the coding standard recommendation for private class members:

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; PHP 4 does not support truly-enforceable private namespaces) are preceded by a single underscore. For example:

_node_get()

$this->_status

Again from my brief glance at D7, this is incorrect. Public method names are in lowerCamelCase, do not use a leading underscore, and are not named using underscores. For variables and methods that are private to the class, the private keyword is not used; the protected keyword is used instead. Underscores are not used.

I don't know how much of this is "Oh, that's just SimpleTest" and how much is recommended convention. Or how much is D7 (that is, PHP5+) specific and would be confusing for people writing for D6.

Please correct the above or clarify it so we can update the coding standards.

Comments

Crell’s picture

Crell commented

Nifty!

PHP's coding standards are for function_name(), ClassName::methodName(). The language itself follows that with language-level OOP code. (DateTime, SPL, and in PHP 5.3 the __callStatic() magic method.) We should follow the same standard. Up until D6 we didn't have any OOP code, so it didn't matter. In D6, we added one class, for the Aggregator parser. That class of course can now be killed anyway as it's PHP 4-based, but any new OOP code should follow the language standard.

The _ for private functions still makes sense. For OOP, yes, we should use real language properties but be *very* careful about when to restrict access. I'd actually add another OOP standard: Never use private. Always use protected or public. That way, you can as a last resort subclass something and muck about with the protected properties.

sdboyer’s picture

sdboyer commented
Title: OOP standards » Panels re: OOP

I'm really glad to be seeing this issue brought up at this point, as I'm one of those performing said stealthy injection. We're going full-blown OO for Panels 3 (when we get there), and even now the various additions to Panels (both core api and api implementations) that I'm writing are increasingly OO, albeit PHP4. Bottom line, I'd really love to have some standards to conform to.

I tihnk Crell's thoughts are right on the money as it regards OOP member properties. Re: using them: if nothing else, it's a good practice to promote, as I think it will increase general awareness within the community about the various new magic methods in PHP5. Re: not using private: a community standard will never stop genuine & compelling use cases for declaring a particular member as private, but having the standard set not to use private ought to discourage people from marking members as private out of ignorance or laziness, which will be of great benefit to drupal's ongoing flexibility.

Of course, re: CamelCase...who's volunteering to rewrite Views2? :)

Crell’s picture

Crell commented
Title: Panels re: OOP » OOP standards

No changing the title!

heather’s picture

heather commented
Component: Coding standards » New documentation

Changed the component to reflect the new component categorization. See http://drupal.org/node/301443

add1sun’s picture

add1sun commented
Status: Active » Postponed (maintainer needs more info)

So any of you "classy" types want to write up a small bit re: OOP to put in the standards or do you feel we need to have a larger dev list style discussion about it first?

Crell’s picture

Crell commented

I'll try to budget some time to add the current de facto standard to the standards docs this week. (Or are those pages still restricted? I may or may not have access to them at this point. :-) )

add1sun’s picture

add1sun commented

The Coding standards page is a regular handbook page now (no more CVS), editable by site maintainers, so you should be fine.

gpk’s picture

gpk commented
Status: Postponed (maintainer needs more info) » Active

Changing status so this issue is more visible in the issue queue!

Have fixed the studlyCaps problem on the coding standards page since it was generating comment, but my limited knowledge/understanding prevents me from doing much more!

marvil07’s picture

marvil07 commented

subscribing

MGParisi’s picture

MGParisi commented
Status: Active » Postponed (maintainer needs more info)

I happen to uncover that this is not a Documentation issue, it is a coding standards issue. I am assuming no one consulted http://groups.drupal.org/coding-standards-and-best-practices

Therefor I will have to say that this is Out of Scope for this discussion. If you have OOP standards set, then we will be able to document them.

Marking this as "needs more information"

stella’s picture

stella commented

subscribing

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented
Status: Postponed (maintainer needs more info) » Fixed

See #8 - most of this had already been fixed.

I added a couple of extra notes to the section on class naming conventions. I think it is fine now.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.