But what’s the difference between “updated” and “modified”? Well, there is none. You can either use “updated” or “modified”, just don’t use both as that is redundant. And whichever column name you choose, use it throughout your database to be consistent!

With singular/plural conventions I mean the following conventions every new baker has to learn while doing his first steps with Cake:

• Table names are plural (e.g. posts, categories, request_tokens)
• Model names are singular (e.g. Post, Category, RequestToken)
• Controller names are plural and ending with “Controller” (e.g. PostsController, CategoriesController, RequestTokensController)

I follow those conventions automatically, but I have to admit I don’t see any real advantages in the distinction between singular and plural names at the moment. On the other hand, the disadvantages are they only work if you use English names (else you have to define your own rules in app/config/inflections.php), they make the learning curve steeper, and if you look at tables as objects it is not that logical to use plural names for them…

Please don’t get me wrong, I think it is a good thing to have naming conventions, but I also think the current conventions could be simplified, to something like:

• Table names are singular (e.g. post, category, request_token)
• Model names are like table names, but camel-cased (e.g. Post, Category, RequestToken)
• Controller names use the model names plus “Controller” (e.g. PostController, CategoryController, RequestTokenController)

You would get all the benefits of naming conventions without having to care whether a name has to be singular or plural. And the conventions would also work for people who prefer to use names in their native languages.

I know, those singular/plural conventions probably won’t disappear, as they are core conventions and a change would affect many Cake applications… At least I learned something about the design of conventions from this example ;-)

According to a comment by gwoo those files should be placed in the vendors folder: “Vendors is fine. Any classes that are not part of the MVC are considered 3rd party classes.”

Sure, this works. Only, it means you have to mix two different concepts: on the one hand you have classes you get from someone else (the “vendor”) and which you usually don’t touch (and often don’t follow the Cake conventions), and on the other hand you develop your own non-MVC classes following the Cake conventions in the same folder. To me this doesn’t feel right…

And so I think there should be a convention like “Non-MVC classes are placed in app/libs” to separate “internal” and “external” libs and to show in the “app” folder the fact that an application (often) consists of utility classes and external libraries.

Such a convention would also help to avoid comments like the following comment for a class defined in a AppModel: “q: Why is this in the app_model file? a: Because we couldn’t really think of a better place. Suggestions are most welcome.”

To use this feature efficiently it makes sense to use a convention to structure your code (the example in the image is unstructured hence it is more difficult to find a certain method). And even if your IDE doesn’t provide such a feature it makes sense to follow a convention as it makes your code more cleaner.

The convention I use is simple: first public stuff, then private stuff, both ordered alphabetically. So a CakePHP file may look like:

class A {
    var $a = ...
    var $z = ...
    var $__a = ...
    var $__z = ...

    function a() {}

    function z() {}

    function __a() {}

    function __z() {}
}

Especially if you have larger files it helps to avoid that you get a messy code structure. And it doesn’t require any additional effort.