Code Style and Quality Standards

Purpose and Scope

This document describes the code style and quality standards enforced in the Laravel Boost PhpStorm Copilot package. It covers the automated tooling used to maintain consistency, the specific coding standards applied, and how these quality checks integrate into the development workflow.

For information about running tests and test coverage, see Testing Framework and Strategy. For CI/CD pipeline automation of quality checks, see CI/CD Pipeline.

Code Quality Tooling Overview

The package uses two primary tools to maintain code quality:

1. Laravel Pint — Automated PHP code style fixer based on PHP-CS-Fixer, configured in pint.json
2. EditorConfig — Cross-editor formatting baseline, configured in .editorconfig

Tool-to-File Mapping

Sources: composer.json58-63 pint.json1-8 .editorconfig1-16

Laravel Pint Configuration

Laravel Pint is configured via pint.json1-8 in the project root. The configuration specifies:

Setting	Value	Purpose
preset	"laravel"	Uses Laravel's opinionated style guide as base
no_unused_imports	false	Allows unused imports (disabled strict enforcement)
strict_comparison	true	Enforces === and !== instead of == and !=
declare_strict_types	true	Requires declare(strict_types=1); in all PHP files

The Laravel preset applies PSR-12 standards with Laravel-specific adjustments, including:

• Line length recommendations
• Array syntax preferences
• Import ordering
• Spacing and indentation rules

Custom Rules Applied

The package overrides the Laravel preset in two specific areas:

Strict Type Declarations

The declare_strict_types rule (enabled at pint.json6) requires every PHP file to open with declare(strict_types=1);. All files under src/ follow this pattern, as can be seen in PhpStormCopilot.php and PhpStormCopilotServiceProvider.php.

Strict Comparison Operators

The strict_comparison rule (enabled at pint.json5) enforces type-safe comparisons throughout the codebase. All equality checks must use === or !== instead of == or != to prevent type coercion bugs.

Unused Imports

no_unused_imports is set to false at pint.json4 meaning Pint will not flag or remove unused use statements. This is a deliberate relaxation of the default Laravel preset behavior.

Sources: pint.json1-8

EditorConfig Settings

The .editorconfig1-16 file provides cross-editor configuration that applies to all file types in the project:

Universal Settings

All files use these baseline settings:

Property	Value	Applies To
charset	utf-8	All files
end_of_line	lf	All files (Unix-style line endings)
indent_size	4	Default for most files
indent_style	space	All files (no tabs)
insert_final_newline	true	All files must end with newline
trim_trailing_whitespace	true	Remove trailing spaces

File-Type Specific Overrides

Markdown Files .editorconfig11-12

Trailing whitespace is preserved in .md files because Markdown uses two trailing spaces to create line breaks.

YAML Files .editorconfig14-15

YAML files (.yml, .yaml) use 2-space indentation instead of 4 spaces to follow YAML conventions.

EditorConfig Rule Inheritance

Sources: .editorconfig1-16

Composer Scripts for Quality Checks

The package defines two composer scripts in composer.json55-63 for code quality management:

composer lint

Defined at composer.json58-60 this script runs pint without arguments, which:

1. Scans all PHP files in src/ and tests/
2. Automatically fixes code style violations in place
3. Reports which files were modified
4. Exits with status 0 if no unresolvable issues are found

Use this during development to auto-format code before committing.

composer test:lint

Defined at composer.json61-63 this script runs pint --test, which:

1. Scans all PHP files in src/ and tests/
2. Reports violations without modifying files
3. Exits with a non-zero status if any violations are found
4. Used in the CI/CD pipeline (see 6.4)

Lint Script Lifecycle

Sources: composer.json55-63

PSR-12 Coding Standards

The Laravel preset in Pint implements PSR-12 standards with Laravel-specific conventions. Key standards enforced include:

File Structure

1. Files must use Unix-style line endings (LF)
2. Files must end with a single blank line
3. PHP opening tag must be on its own line
4. Strict types declaration must be after opening tag
5. Namespace declaration must be after strict types
6. Use statements must be after namespace

Naming Conventions

Element	Convention	Example
Classes	PascalCase	PhpStormCopilot
Methods	camelCase	systemDetectionConfig()
Properties	camelCase	$mcpConfigPath
Constants	UPPER_SNAKE_CASE	DEFAULT_PORT
Namespaces	PascalCase	Revolution\Laravel\Boost

Formatting Rules

• Indentation: 4 spaces (no tabs)
• Line length: Soft limit of 120 characters (not enforced)
• Blank lines: Single blank line between methods
• Braces: Opening brace on same line for methods/functions
• Spacing: Single space after keywords and before opening parentheses

Type Declarations

All methods must include type declarations where possible:

• Parameter types must be declared
• Return types must be declared
• Nullable types use ? prefix
• Union types use | separator (PHP 8.0+)
• Property types must be declared (PHP 7.4+)

Sources: pint.json2 composer.json18

Quality Standards Enforcement

Quality Enforcement Across the Development Lifecycle

Development Workflow

1. During Development: Editor applies .editorconfig rules automatically
2. Before Commit: Optionally run composer lint to auto-fix style issues
3. Before Push: Run composer test and composer test:lint to verify
4. In CI/CD: Automated checks run composer test:lint to enforce standards

Failed Quality Checks

When composer test:lint fails:

1. Review the output showing which files and lines have violations
2. Run composer lint to auto-fix most issues
3. Manually fix any issues that cannot be auto-fixed
4. Re-run composer test:lint to verify
5. Commit the fixes

Sources: composer.json55-63 pint.json1-8 .editorconfig1-16

Integration with Testing

Code style checks are separate from functional tests but run in the same CI/CD pipeline. The quality check workflow integrates with the testing strategy documented in Testing Framework and Strategy:

Check Type	Command	Purpose	When to Run
Style Check	composer test:lint	Verify code formatting	CI/CD, pre-push
Style Fix	composer lint	Auto-fix formatting	During development
Unit Tests	composer test	Verify functionality	CI/CD, pre-push, during dev
Coverage	composer test:coverage	Generate coverage report	CI/CD, on-demand

All checks must pass before merging pull requests. The CI/CD pipeline enforces this by running both test:lint and test scripts, as detailed in CI/CD Pipeline.

Sources: composer.json55-63