These are really bad practices.

Sorry Manuel.

I agree with the topic of this article and the use of PHP OOP code. However the code samples in this article are really bad and outdated.

The use of "var" is deprecated it should be replaced with a visibility component: public/protected/private as well as all the methods of the class.

Also the modern Coding Standards all use camelCase for method names as opposed fo function_name.

And it would be nice to reference namespaces or even traits to drive adoption of new versions.

Please adjust the code samples to spread good practices to new developers, this code is dated back to PHP4.

It does not seem that you read the article carefully.

The article is not about coding styles. The article is about explaining to people why encapsulation helps them write better organized code that is more reusable between projects and can be reused by other people without colliding functions and variable names.

Anyway, addressing your objections, maybe you do not know how PHP works internally, but when PHP code is compiled by Zend engine, variables declared as var or public result in the same Zend OP codes.

This means that in practice it does not make a difference if you declare it as var or public. It is a matter mainly a matter of style.

Also if you read the PHP manual it says public and var are compatible.

"Note: The PHP 4 method of declaring a variable with the var keyword is still supported for compatibility reasons (as a synonym for the public keyword). In PHP 5 before 5.1.3, its usage would generate an E_STRICT warning."

So var is not deprecated. If it was deprecated it would trigger an E_DEPRECATED warning. In case you do not know E_STRICT and E_DEPRECATED are different. E_DEPRECATED means it is discourage and E_STRICT is to help those more pedantic to locate code that conforms to more demanding coding styles.

All this means that var will always work and will never be deprecated in all PHP versions unless PHP core people decide otherwise.

As for namespaces, if you read the article again, you may notice it explains that it serves to avoid class name collision. It also explains that in most cases namespaces are not really necessary. Try reading the article with more attention next time.

As for traits, inheritance, visibility modifiers, all other OOP features, as explained it was not the point of this article in particular. The point was just explaining people that program mostly in global code to move on to OOP. Even Wordpress was mentioned as an example.

Anyway, if you are willing to write a constructive article about those other features, feel free to submit a post here. I am sure it will be well appreciated.

phpclasses.org/blog_post.html

modern Coding Standards say to use camelCase? Which modern "Coding Standards" are you using? Your own? It does not make much difference. You might personally always use one, or your company might have a policy to use one, but, as far as I know, there are no official coding standards for PHP. Please correct me if I'm wrong.

First of all, nice article!

I agree on all that you mentioned in your reply to previous commenter except for the matter regarding the var keyword.

On php.net it says:

"The PHP 4 method of declaring a variable with the var keyword is still supported for compatibility reasons (as a synonym for the public keyword). In PHP 5 before 5.1.3, its usage would generate an E_STRICT warning."

Do you still believe it's a good idea to encourage the use of "var" when declaring class properties? Even though it will translate into the same thing as when using "public" by Zend engine, it still feel as bad practice now a days. With the topic of this article in mind, it actually surprises me if you believe so.

Once again, great article. Keep up the good work!

To be clear I was not encouraging or discouraging the use of var to declare variables.

It is a valid way to declare variables in all past, present and future PHP versions. It is the same as using public, except that unlike public it works in past PHP versions that many people are still using. The article was meant to be PHP version agnostic.

As I said, using var works perfectly well, it is not a sin and you will not go to hell if you use it. So the claim that it is a bad practice is your opinion, which I respect, but I do not agree.

The use of var will trigger E_STRICT warnings which are meant to please developers with a more pedantic style that want to write code that looks more like Java.

Right, it seems Rafael is not aware that PHP function names are case insensitive, so it does not matter the case of the function names. It is more a matter of preference style.

In Java function names case matters and in the Java world there is a standard for names dictated by Sun. But PHP is not Java. There is no standard that is well accepted by the whole PHP community.

There were attempts to establish different standards but those were defined by a closed number of people that the vast majority of the PHP community does not know or respect.

Unfortunately the PHP community is not consensual. Attempts like Rafael's to criticize other people's styles by imposing their styles only result in less respect for them. They do not know how to be diplomatic and persuasive. They think that being hostile and demanding will get anywhere. The only thing they get is to stay there talking alone with the walls.

Hi Manuel,

I think that Rafael want just pinpoint some good practices, they are already adopted under coding guide lines by Zend Framework, Symphony, and many others frameworks like standards.

The really reason of why you should not use the "_" for a classe name is beacause before php 5.3, the underscore whas used as a namespace delimiter, so for the class my_foo_Object the autoloaders systems was used to include "my/foo/Object.php". (that is the PSR-0 Standard enabling using third party components on PHP frameworks)

You're totally right for the case insensitive fact, but on *nix systems, the translated path is case sensitive (and that's my intuition, the case insensitive comes with a cost, and could be removed from next versions)

Don't blame Rafael, I also totally share his point of view, and I think he was just trying to open the debate about good pratices (that's a real demand : take a look at PMD for example...)

Anyway, nice talk and intro to OOP, maybe for advanced users you could also introduce some principles like S.O.L.I.D. (maybe in another post).

CodeIgniter framework uses function_name and so do some other frameworks. I think naming standards should be introduces as "these are some commonly used ones and you should pick one and stick with it" but I don't see anything wrong with using the function_name standard.

I think you are referring to zend naming conventions which are widely accepted but none the less are zend naming conventions, not PHP naming conventions.

Just my opinion.

Thank you for pointing out that 'var' is deprecated. I still see a lot of examples using it and did not know it was deprecated. It does make more sense to me to explicitly declare the scope rather than just calling it a var though.

What is a good or bad practice is not consensual.

Anyway, what I already repeated dozens of times is that good or bad practices were not the scope of this article. The article was about why OOP is a good thing in terms of avoiding namespace collision to organize better code and promote reuse.

It would take many articles to explain what can be or not be a bad practice. Adding that to the article would not help in making the article more succint as it needs to be for people that have an hard time to grasp OOP.

Right, some people are so in love with certain frameworks that they have an hard time accepting that the vast majority of PHP community does not care about their favorite framework and whatever are the conventions those framework developers follow.

Other than that, using var is not deprecated. If using var was deprecated, it would throw a E_DEPRECATE warning, not E_STRICT which what happens in newer PHP versions.