Navigating PHP Standards: Rules You Can Ignore Without Errors, But Shouldn't

In the world of PHP development, adhering to coding standards is essential for creating maintainable and readable code. Standards like PSR-1, PSR-12, and PSR-4 provide valuable guidelines that help developers write better PHP code. Many of these rules can be flexible. Not following them won’t cause immediate errors. However, it’s important to know that ignoring them can affect code quality over time. This blog shares important rules for writing PHP code. These rules are not strictly required but are best practices. Following them can help improve readability and maintainability. We’ll accompany each rule with practical examples to illustrate their importance.

PSR-1 outlines essential guidelines for PHP coding, serving as the foundation for writing clear and consistent code. In this section, we’ll explore some specific rules within PSR-1 that are particularly relevant to our discussion. These rules are not strictly required, but they are good practices. They can improve the quality and maintainability of your PHP code.

1. Opening Tags:

• Best Practice: Use <?php or <?= for opening PHP tags.
• Flexibility: Short tags like <? may work if short_open_tag is enabled, but they’re not recommended.

  // Best practice
  <?php
  echo "Hello, World!";
  
  // Still works if short_open_tag is enabled (not recommended)
  <?
  echo "Hello, World!";
  

2. Class Naming:

• Best Practice: Use PascalCaps for class names.
• Flexibility: A class named myclass will function correctly but lacks conventional clarity

  // Best practice
  class MyClass
  {
      // ...
  }
  
  // Still valid (not recommended)
  class myclass
  {
      // ...
  }
  

3. Method Naming:

• Best Practice: Use camelCase for method names.
• Flexibility: A method named my_method will still work but strays from the standard.

  // Best practice
  public function myMethod()
  {
      // ...
  }
  
  // Still valid (not recommended)
  public function my_method()
  {
      // ...
  }
  

As we delve into PSR-12, we find more detailed guidelines that promote consistency. Here are some rules that can be bent without breaking the code:

1. Function and Class Braces:

• Best Practice: Opening braces for functions and classes should be on the next line.
• Flexibility: While you can place the opening brace on the same line without causing errors, it's not recommended.

  // Best practice
  class MyClass 
  {
      public function myMethod() 
      {
          // ...
      }
  }
  
  // Still valid (not recommended)
  class MyClass {
      public function myMethod() { 
          // ...
      }
  }
  

2. Function Arguments:

• Best Practice: Specify types for function arguments to enhance code clarity and type safety.
• Flexibility: While specifying types is not mandatory, omitting them can lead to unexpected behavior.

  // Best practice
  function functionName(int $arg1, string $arg2): string
  {
      return "Result";
  }
  
  // Valid but not recommended
  function functionName($arg1, $arg2)
  {
      return "Result";
  }
  

• Best Practice: Include a space after the colon when specifying return types or parameter types.
• Flexibility: While you can omit the space, it can reduce readability.

  // Best practice
  function functionName(int $arg1, string $arg2): string
  {
      return "Result";
  }
  
  // Still valid (not recommended)
  function functionName(int $arg1, string $arg2):string
  {
      return "Result";
  }
  

3. Control Structures:

• Best Practice: Control structures should have a space after the keyword.
• Flexibility: Omitting the space won’t cause a syntax error.

  // Best practice
  for ($i = 0; $i < 10; $i++) {
      // ...
  }
  
  // Still valid (not recommended)
  for($i=0;$i<10;$i++) {
      // ...
  }

4. Type Casting:

• Best Practice: Use spaces around type casting.
• Flexibility: You can write (int)a without spaces, and it will still work

  // Best practice
  $value = (int) $a;
  
  // Still valid (not recommended)
  $value = (int)a;
  

5. Operators:

• Best Practice: Operators should be surrounded by spaces.
• Flexibility: Omitting spaces won't cause errors but reduces readability.

  // Best practice
  $result = $a + $b;
  
  // Valid but not recommended
  $result=$a+$b;
  

PSR-4 provides a way to autoload classes based on their namespace. While many rules here are more stringent, there are still flexible points to consider:

Namespace Declaration:

• Best Practice: Namespaces should match the directory structure.
• Flexibility: If they don’t match, your class won’t autoload, but it can still be included manually.

  // Properly structured
  namespace App\Models;
  
  class User { }
  
  // Still works (manual inclusion required)
  namespace MyApp;
  
  include 'User.php'; // Manual inclusion is necessary