Why this matters
Specifying visibility improves code readability and maintenance by clearly defining public interfaces versus internal details. It enforces encapsulation and avoids accidental misuse of internal members.
Always specify access levels (public, private, protected) when declaring class properties and methods. Don’t use the old `var` keyword for properties. Explicit visibility clarifies intent and prevents unintended access.
Specifying visibility improves code readability and maintenance by clearly defining public interfaces versus internal details. It enforces encapsulation and avoids accidental misuse of internal members.
Side-by-side examples engineers can pattern-match during review.
<?php
class User {
var \$name;
function setName(\$name) {
\$this->name = \$name;
}
}
?><?php
class User {
public string \$name;
public function setName(string \$name): void {
\$this->name = \$name;
}
}
?><?php
class User {
var \$name;
function setName(\$name) {
\$this->name = \$name;
}
}
?><?php
class User {
public string \$name;
public function setName(string \$name): void {
\$this->name = \$name;
}
}
?>From the same buckets as this rule.
For changes that affect architecture, data models, external APIs, security posture, deployment topology, or cost (>10%), create an ADR in docs/adr/ using the standard template (Context, Decision, Consequences) and link the PR and issue IDs.