PEAR2 Class Naming

From PEAR Wiki

Jump to: navigation, search


Contents

[edit] Summary

This RFC has been moved to [Here]

[edit] Information

[edit] Document Information

[edit] Author(s) Information

[edit] Legal Information

  • This RFC is under the BSD License

[edit] Discussion List

  • Currently only pear-group; future is pear-dev[[1]]

[edit] Introduction

With the introduction of namespaces in PHP 5.3, the PEAR1 rule of Package_Subpackage_ClassName naming (for creating pseudo-namespacing) is no longer necessary. Package naming rules will be set by the PEAR2_Naming_Standards RFC, whereas class naming rules are addressed here in this RFC.

The naming of individual classes retains these PEAR1 rules:

  • Start with capital letter, e.g. class Foo {}
  • CamelCase for multi-worded class names, e.g. class FooBarBaz {}
  • Abbreviations only start with capital letter, e.g. class MrClean {}
  • Acronyms should be fully capitalized, e.g. class PEARTree {}

New guidelines for PEAR2:

  • syntax/scope hints that are desired to be in the class name should be suffixed rather than prefixed, e.g. abstract class FooAbstract {}
    • such suffixing is not preferred, but neither is it outlawed

[edit] Issues

  • there has been some discussion/debate around various forms of "Hungarian Notation" in class naming, particularly for Abstract and Interface classes

[edit] Proposed Solution

Initial rules and guidelines:

  • no suffix for an Abstract or Interface class name is necessary, nor is it preferred
    • attempts to misuse abstract classes and interfaces in userspace code will be caught by PHP anyway
    • any extra naming is effectively just for code readers to shortcut/avoid reading the code documentation, which isn't a best practice to promote
  • any extra naming should be a full legible word, not a cryptic letter/abbreviation (e.g. FooAbst, FooA)
    • this follows other well-known conventions (e.g. Java)
  • an "Abstract" suffix is tolerable, e.g. abstract class FooAbstract {}, though neither necessary nor preferred
  • an "Interface" suffix should not be used at all, as usage of "interface PublishableInterface {}" as "class Publisher implements PublishableInterface {}" seems less readable.

[edit] References

  • PEAR1 Coding Standards for Class Naming -- [[2]]
  • Weierophinney's original post about potential naming conflicts once Namespaces arrive -- [[3]]
Personal tools