PSR-2 is a coding style guideline for PHP developed by the PHP-FIG (Framework Interop Group) to make code more readable and consistent, allowing development teams to collaborate more easily. The abbreviation “PSR” stands for “PHP Standards Recommendation”.

Key Points in PSR-2:

1. Indentation: Use four spaces for indentation instead of tabs.
2. Line Length: Code should ideally not exceed 80 characters per line, with an absolute maximum of 120 characters.
3. File Structure: Each PHP file should either contain only classes, functions, or executable code, but not a mix.
4. Braces: Opening braces { for classes and methods should be on the next line, whereas braces for control structures (like if, for) should be on the same line.
5. Spaces: Place a space between control keywords and parentheses, as well as around operators (e.g., =, +).

Example

Here’s a simple example following these guidelines:

<?php

namespace Vendor\Package;

class ExampleClass
{
    public function exampleMethod($arg1, $arg2 = null)
    {
        if ($arg1 === $arg2) {
            throw new \Exception('Arguments cannot be equal');
        }

        return $arg1;
    }
}

PSR-2 has since been expanded and replaced by PSR-12, which includes additional rules to further improve code consistency.

PSR-1 is a PHP Standards Recommendation created by the PHP-FIG (Framework Interop Group) that defines basic coding standards for PHP code style and structure to ensure interoperability between different PHP projects and frameworks. Its main purpose is to establish a consistent baseline for PHP code, making it easier to understand and collaborate on projects across the PHP ecosystem. PSR-1, also known as the Basic Coding Standard, includes several key guidelines:

1. File Formatting:

   • All PHP files should use only <?php or <?= tags.
   • Files should use UTF-8 encoding without BOM (Byte Order Mark).

2. Namespace and Class Names:

   • Class names must be declared in StudlyCaps (PascalCase).
   • PHP classes should follow the “one class per file” rule and be defined within namespaces that match the directory structure.

3. Constants, Properties, and Method Naming:

   • Constants should be written in all uppercase letters with underscores (e.g., CONST_VALUE).
   • Method names should follow camelCase.

4. Autoloading:

   • PSR-1 encourages using PSR-4 or PSR-0 autoloading standards to make class loading automatic and avoid manual include or require statements.

PSR-1 is considered a foundational standard, and it works in tandem with PSR-2 and PSR-12, which define more detailed code formatting guidelines. Together, these standards help improve code readability and consistency across PHP projects.

"Lines of Code" (LOC) is a software development metric that measures the number of lines written in a program or application. This metric is often used to gauge the size, complexity, and effort required for a project. LOC is applied in several ways:

1. Code Complexity and Maintainability: A high LOC count can suggest that a project is more complex or harder to maintain. Developers often aim to keep code minimal and efficient, as fewer lines typically mean fewer potential bugs and easier maintenance.

2. Productivity Measurement: Some organizations use LOC to evaluate developer productivity, though the quality of the code—rather than just quantity—is essential. A high number of lines could also result from inefficient solutions or redundancies.

3. Project Progress and Estimations: LOC can help in assessing project progress or in making rough estimates of the development effort for future projects.

While LOC is a simple and widely used metric, it has limitations since it doesn’t reflect code efficiency, readability, or quality.

Cyclomatic complexity is a metric used to assess the complexity of a program's code or software module. It measures the number of independent execution paths within a program, based on its control flow structure. Developed by Thomas J. McCabe, this metric helps evaluate a program’s testability, maintainability, and susceptibility to errors.

Calculating Cyclomatic Complexity

Cyclomatic complexity $V(G)$ is calculated using the control flow graph of a program. This graph consists of nodes (representing statements or blocks) and edges (representing control flow paths between blocks). The formula is:

$$V(G)=E-N+2P$$

• $E$: The number of edges in the graph.
• $N$: The number of nodes in the graph.
• $P$: The number of connected components (for a connected graph, $P=1$).

In practice, a simplified calculation is often used by counting the number of branching points (such as If, While, or For loops).

Interpreting Cyclomatic Complexity

Cyclomatic complexity indicates the minimum number of test cases needed to cover each path in a program once. A higher cyclomatic complexity suggests a more complex and potentially error-prone codebase.

Typical Ranges and Their Meaning:

• 1-10: Low complexity, easy to test and maintain.
• 11-20: Moderate complexity, code becomes harder to understand and test.
• 21-50: High complexity, code is difficult to test and error-prone.
• 50+: Very high complexity, indicating a strong need for refactoring.

Benefits of Cyclomatic Complexity

By measuring cyclomatic complexity, developers can identify potential maintenance issues early and target specific parts of the code for simplification and refactoring.