Why do people often omit public/private/protected when declaring a class?_问答_开发者

I keep seeing this format in recent codes and even here:

c开发者_运维技巧lass Class {
    function this() {}
}

instead of

class Class {
    [public/private/protected] function this() {}
}

Isn't it recommended to always specify the function scope?
Isn't the first approach an old one?
How are, in the first approach, defined private and protected functions?

when you declare a function without any keyword that is public by default.

Isn't it recommended to always specify the function scope?

You have to define function scope if you are going to use them as private or protected.

Isn't the first approach an old one?

What's the old and new if they are still accepted by PHP.

How are, in the first approach, defined private and protected functions?

you can not with first approach you have to use keywords.

Yes, probably.
It's hard to quantify how new or old a technique is. It may have been less non-recommended in the past, when classes were relatively new in PHP.
"Class methods may be defined as public, private, or protected. Methods declared without any explicit visibility keyword are defined as public."

The PSR-2 coding standard explicitly requires the visibility modifier to be used both for properties and for methods.

Using public is not required though because PHP 5 and 7 is backwards compatible to version 4, which only had public visibility for everything, so it is the default setting.

However, omitting it will raise questions - like you did. Humans are very good at detecting patterns and errors in patterns. What would you think of a piece of code that uses protected or private everywhere (because you have to), but randomly omits public. Is this an error? Has it been done intentionally? What kind of secret behavior is supposed to be triggered by this? Or is this still PHP4-code that hides some nasty compatibility issues? As a developer, you don't want to ask these questions, and you don't want to have to find the answers.

public is optional, but PSR-2 decided to require it. Go with the standard recommendation.

Also note that there has been a proposal to deprecate and remove the var modifier for properties and entirely replace it with public. The proposal also lists a code analysis of the top 10'000 packages on Packagist, stating that 94% of all classes in this code base use public exclusively, the remaining 6% of classes using var come from four bigger packages that most likely still try to be PHP4 compatible, with "Simpletest" (a unit test framework targeted at PHP 4) being in the lead.

There is no such static code analysis for visibility modifiers for methods that I know of, but the trend is clearly visible: Get rid of old PHP4-isms.

Yes it is. It's always recommended to specify the function/property visibility.
Yes it is. The version without visibility modifiers has been around until PHP4. With PHP5 visibility modifiers have been introduced. Due to backwards compatibility for legacy code the version without visibility modifiers is still accepted and treated as if there was a public visibility modifier.
PHP4 didn't know anything about visibility, so you cannot define private or protected members with this visibility-modifier-less syntax.

PHP was born as a (lazy, duck typed) scripting language, and people are still using it this way. Most PHP programmers don't have an idea of what OOP is, I know this problem very well because I started with PHP, and that did cost me a lot of work later. About 90% of PHP code you see around is messy and outdated as of object orientation, readability, encapsulation, etc... At least 50% is pure crap. :(

I can't tell you how much OOP programmers are suprised when they discover that "dependency injection" is actually considered an innovative design pattern by PHP developers, and it needs to be explained.

However, PHP4 had no scope operators such private or protected. At that time, you used to declare a method prepending one or more underscore(s) to the method name in order to indicate it is not meant to be called from external classes.

Yes it is recommended
Yes it is, in an OOP perspective
Naming conventions that hopefully had to be understood by clients

Foremost PHP4 compatiblity and affinity.

Some developers (like me) omit the accessibility modifiers because they have little bearing on scripting languages. Real OOP languages like Python or Javascript don't have private or protected attributes, and don't need it. In PHP it's a bit different, but it doesn't make sense to always apply that syntactic sugar. I'll personally make it a point to reserve it for useful applications.

Many PHP coders are unaware of the original purpose of "encapsulation", as it doesn't apply to uncompiled code beyond logic visibility. It adds in fact a bit more fragility in PHP as it blows up errors at runtime, instead of compile-time (like in C++).
And I can't hold back on saying it again: Many coders also apply it solely as cargo cult programming idiom to simulate Java-like syntax (to make up for PHPs perceived/past lack of OOP constructs).