Your class/interface naming convention?

Lord_Yggdrasill

Well I was wondering what naming convention PHP programmers normally use. It seems that there is not a universally accepted pattern here, but I do believe one or two of them are more favorable than the others?

Mine is actually quite simple. Here is a description of it, you can skip this part if you aint interested. This topic is for discussing naming convention though.

My class names are all noun that models real entity, concrete classes sometimes have a portion of their parent abstract class' names. For instance, the UserContainer and ItemContainer concrete classes both extend Abstract Container class. I do not have special naming patterns for final classes though.

On the other hand my interface names are so far all adjective with specific suffix. The suffix -ive usually implements a method a class can do, while the suffix -able usually implements a method a class can be done. Good example is Creative and Creatable for factory methods. The former is used by factory classes with create() method, while the latter is used by classes whose instances can be created through factory classes with a getCreator() method that reference to its 'production factory'.

I have yet to begin using namespace yet, will give a try in a few weeks. I am running PHP 5.3.x so I aint gonna worry about Trait for this time being, but I know naming will be more complicated once we are adding lots of trait to our projects?

I believe the naming convention I use is quite common in object oriented programming languages such as Java, in which noun and adjective are used for class and interface names. I also heard that some programming languages use the prefix method in which each abstract class begins with a prefix A and each interface begins with a prefix I. How many of you are advocate for this pattern? At the very last I recall some frameworks such as Zend and Symfony simply add a long suffix such as -Abstract and -Interface, not sure if it is really a good idea or not?

Bonesnap

Coming from a Java and .NET background I used to use camelCase with my naming conventions, and classes would start with an uppercase letter. For example, HumanBeing. This trend continued on into my web development career however with my increased work with WordPress at my new job, I've started adopting their naming conventions and have dropped the camelCase. Now if I were creating a class for human being it would be Human_Being. Not much different, I guess. Variables would be something like $human_being instead of $humanBeing. Functions are all lowercase with underscores, like human_being(). Other developers in my office use camelCase, so sometimes it's fun reading others' code.

dalecosp

Usually, around here we use NutCase and sometimes BasketCase.

I've tried to get them to install a PastryCase, but they aren't interested. 😃

traq

namespaces: [font=monospace]lowercase[/font]

abstracts, interfaces, and traits: [font=monospace]UPPERCASE[/font]
(trait method|property names are named normally but prefixed with the trait name)

[final] classes: [font=monospace]CapitalizedCamelCase[/font]

constants: [font=monospace]UPPERCASE_WITH_UNDERSCORES[/font]

public methods and properties: [font=monospace]camelCase[/font]

nonpublic methods and properties: [font=monospace]_lowercase_with_leading_underscore[/font]

It's really only within the past year that I've started formalizing my naming conventions, so it's not really set in stone.

If a particular project has naming conventions in place, I use them instead.

NogDog

Which raises the issue of using 3rd-party classes, packages, libraries, etc. that use different conventions, screwing up whatever consistent nomenclature you're trying to use. 🙂

dalecosp

Yup, yup. And, really, a gamut of "higher level" questions including whether to customize 3rd party packages, or just whine/cajole/pay the vendors to implement the features you need.

Bonesnap

dalecosp;11012855 wrote:
Usually, around here we use NutCase and sometimes BasketCase.

I've tried to get them to install a PastryCase, but they aren't interested. 😃

At least it's not a ColdCase!

NogDog

For the record, when doing stuff for myself:

$camelCase = new CamelCase(SOME_CONSTANT);

class CamelCase implements ICamelCase {}

I've never gotten into using any indicators for private versus public methods/variables -- just never really saw the need (perhaps because I didn't really get into OOPhp until PHP 5 when "private" was added?).

traq

NogDog;11012901 wrote:
I've never gotten into using any indicators for private versus public methods/variables -- just never really saw the need (perhaps because I didn't really get into OOPhp until PHP 5 when "private" was added?).

Actually, I started doing _the_underscore_thing before I started making use of "private", just as an indication of which methods were only supposed to be used internally (by other methods).

Lord_Yggdrasill

Well I dont use underscore for private fields and methods either. A good reason to use underscore is that visibility did not exist back in PHP4 when OOPHP was first introduced, programmers simply used underscore as indicator that a property was not supposed to be accessed outside of the class itself. With PHP5, there's really no need to use underscore with the private keyword available.

traq

Lord Yggdrasill;11013259 wrote:
Well I dont use underscore for private fields and methods either. A good reason to use underscore is that visibility did not exist back in PHP4 when OOPHP was first introduced, programmers simply used underscore as indicator that a property was not supposed to be accessed outside of the class itself. With PHP5, there's really no need to use underscore with the private keyword available.

the same reason is still valid - it serves as a reminder/hint to the programmer (and/or future programmers).

as you said, PHP never cared one way or the other.