Naming rules of your variables and classes

Is there a list of keywords and rules used in naming?
(for variables, classes, methods etc)
I think I’m not the only one that thinks a bit when it comes to some names.

Some actions may have standard names (get, set, load) and it’s easy to find a name but some are a bit difficult to name.

Example 1: actions

    $this->setName('George') // will set a property of the class
    $this->getName() // will get a property of the class

OK, all good. Now, I’d like to insert a record.

    $this->addName('george')
    // or, should I use?
    $this->insertName('george')
    // when to use add, insert, create, make
    // is there a set of rules?

Example 2: properties and variables

Some user has an active flag of type int.

    $userObject->active
    // or
    $userObject->isActive

Problem to solve:
I have a method that will return a list of articles that have keys as status. This is in the class articles. So, the output will look like this:

'active' => last article that was approved
'pending' => last pending article, that needs approval
'rejected' => last rejected article

How would you name this method?

I think we should create a standard, as we have PSR2 for writing code, a standard for naming.
Thoughts?

Well in general, addSomething() means that you will append a record to the end of the list, while insertSomething() means you can put it anywhere inside the list. A good example is this:

$list->addElement($element) //add element to the last index.
$list->insertElement($element, 5) //insert element to the fifth index.

But of course, there is not a standard/convention on the web that dictates you to follow the rules, so you can name it the other way around. I am not sure if its necessary to have such a naming standard globally, but for each individual project/library, its good to be consistent.

2 Likes

I definitely agree with this. And further, if you’re in a team that works together regularly, you can have internal standards that, even if not formal, are just the norm for your group, allowing you to work together a little more efficiently. Even on your own, having a pattern helps you when you return to it later.

As to your problem, what about something like getLastArticles() or something in that vein?

Why would you set a key as the status? Keys really shouldn’t be used to find values or to set as flags.

I would say, these are all status values for a “status” property and thus, the methods can be setStatus(), getStatus() and so on.

Scott

[quote=“Hall_of_Famer, post:2, topic:203385”]
Well in general, addSomething() means that you will append a record to the end of the list, while insertSomething() means you can put it anywhere inside the list.
[/quote] Nice thinking! That’s what I’d like to find, some logical explanation of some verbs.

[quote=“jeffreylees, post:3, topic:203385”]
As to your problem, what about something like getLastArticles() or something in that vein?
[/quote] Sounds good but I’m more interested how to put the fact that it’s “organized” by something.
getLastArticles() means you will get last articles, without any other specification.

My problem is that getLastArticlesByCategory() would lead to a parameter, the category to select by. I’m thinking at something like getLastArticlesGroupedByCategory(). And here we can create a standard (just a simple example) so all returns that have array with keys should have the name …GroupedBy…

I must open a github branch and begin to create this standard :smile:

[quote=“s_molinari, post:4, topic:203385”]
Why would you set a key as the status? Keys really shouldn’t be used to find values or to set as flags.
[/quote] This is not the point of the topic, it’s just a simple example of a return that is not int, string or other specific type.

I am glad you find my answer helpful. But anyway, whats more important than a hard standard is consistency. So pick a naming pattern and stick to it.

Ok, reading your answer above, I’d say, the name of a method shouldn’t necessarily indicate the data returned or in what manner it is returned (as in how it is organized). The name of a method should simply describe the behavior it gives to the class.

Another take on this, why have specfic methods for every grouping or order or whatnot? How about method arguments, which help describe and give the method abilities? Like

function getArticles($newest = true, $returnStatuses = true, $groupedBy = null)

Scott

[quote=“Hall_of_Famer, post:6, topic:203385”]whats more important than a hard standard is consistency. So pick a naming pattern and stick to it.[/quote] I know. It’s not so easy when you work with 20 other programmers :smile:

[quote=“s_molinari, post:7, topic:203385”]
The name of a method should simply describe the behavior it gives to the class.
[/quote] True. It’s all about what it does.

[quote=“s_molinari, post:7, topic:203385”]
Another take on this, why have specific methods for every grouping or
order or whatnot? How about method arguments, which help describe and
give the method abilities?[/quote] Maybe my example was not the best and maybe a good (great) rule is to keep it simple, including naming.

Thanks guys for your opinions!
I will try to create some examples for me, to improve my naming ability.

It is provided that you have the naming standards to follow documented and use peer review to enforce them.

I am currently reading a book, “The Object Oriented Thought Process” by Matt Weisfeld and in it Matt says that writing contracts is way for you to determine standards within the code being built. In the book, Matt describes interfaces and abstract classes being a form of contract. The idea is, the names of methods used in the interface and names of abstract methods in the abstract class, have to be “reused” by the coder extending the abstract class or implementing the interface.

This is sort of a side note, but also reading around the Internet about abstract classes and interfaces in PHP, I’ve learned that with the coming of traits, the purpose of code reuse in an abstract class is superfluous, making the use of an interface with traits the most flexible and powerful design option. (i.e. for making contracts / making code standardized).

Of course, contract by design entails a bit more than just the naming of methods in interfaces and creating traits, but the methodology supports what you are aiming for. Standardization within the code. I think that is a very good thing to strive for too. :smile:

Scott

Well abstract classes still have their uses, and I actually prefer it than traits. Traits in PHP are not like they are in Scala, they are more close to mixins. The implementation is static access and traits can be converted to static methods with ease, which is a sign of something bad. It can be beneficial to use traits sparingly, but abusing traits and use it in places of abstract classes can result in undesirable consequences. Read this article if you want to read the pitfalls of traits in PHP:
http://www.whitewashing.de/2013/04/12/traits_are_static_access.html

This is an article I read, which explains better why traits with interfaces is a more flexible means to code than using abstract classes. It boils basically down to the general rule, it is better to use composition over inheritance.

http://www.garfieldtech.com/blog/beyond-abstract

And if you missed the link to Anthony Ferrara’s article, it is also an interesting read.

Edit: Interesting, I found this article too from Anthony. http://blog.ircmaxell.com/2011/07/are-traits-new-eval.html At the end, he also says he is a proponent of traits. He is just warning about using the hammer, when trying to screw in screws.

Scott

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.