Class naming conventions

Well think about this, let's say you have a user who can register on your site and you have a company that can register on your site. If they both have the RegisterCommand, how do you know which one you need to use? Of course if you have your namespace correct then there won't be any issue. But it's not readable anymore!

Jeffrey always talks about getting stuff clear and keeping it readable. You need to think for yourself, if I come back to my code 6 months later do I still understand what RegisterCommand means to me or is RegisterUserCommand better for me?

In my opinion I would say use the RegisterUserCommand ;)

+1

In Zend Framework the Classname had (has?) to reflect the Pathe where the class sits due to autoloading and, after getting used to this naming convention and following it, it trned out as being very useful. I'd suggest as well to use this style of coding.

@frezno It was forced by PHP having no namespaces not that long time ago.

Currently using SomePackage_SomeModule_FancyClassName is rather not prefered way of handling things and that's true for ZF for a long time now as well:

http://framework.zend.com/manual/1.12/en/coding-standard.naming-conventions.html

The rationale for the change is due to namespace usage. As we look towards Zend Framework 2.0 and usage of PHP 5.3, we will be using namespaces. The easiest way to automate conversion to namespaces is to simply convert underscores to the namespace separator

@philthathril I would say, just like the title says - a convention, so based on opinions. I prefer not doing such things:

Domain/Users/Commands/RegisterUserCommand.php

since the class already has its path in the namespace, so there is no way to confuse it with something else:

Domain\Users\Commands\Register

// if you need distinction in given class, then alias it
use Domain\Users\Commands\Register as RegisterUser[Command] // or whatever fits your code

it is self-explanatory, while

Domain\Users\Commands\RegisterUserCommand

is redundant. Again, it's my opinion on how things should be clarified and simplified, and the opinion is like ass - everyone has his own.

Thanks for the input. I've always been an advocate for not being redundant when naming classes and methods. For example, if I'm in a User class, I would not do:

public function createUser() {...}

I would do:

public function create() {...}

However, I think for this particular case, I am going to be redundant in the class name despite the path which already provides the context of the class for several reasons:

1. Easier grep'ability - I would like to be able to search for RegisterUserCommand in my codebase instead of needing to specify the full path to determine which RegisterCommand I'm looking for.
2. Ability to immediately recognize the context of the class. When I see RegisterUserCommand I know immediately and exactly what it's referring to. When I see RegisterCommand (which I haven't aliased during the import), I now have to examine the surrounding context or skip to the top of the class to determine what it's referring to.

Like others have pointed out, it's all opinion! Heck, I may change my mind 6 months from now when I'm a thousand classes into the project. :P Thanks again all.