Skip to main content

Code of Conduct & Engineering Standards

This document defines both:

  1. Our Community Code of Conduct
  2. Our Engineering & Coding Standards

It applies to all contributors, maintainers, reviewers, and collaborators across all repositories and environments.

Part 1: Community Code of Conduct

Our Pledge​

We pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

We commit to fostering an open, inclusive, respectful, and professional environment.

Expected Behavior​

Examples of behavior that contribute to a positive environment:

  • Demonstrating empathy and kindness
  • Respecting differing opinions and viewpoints
  • Giving and gracefully accepting constructive feedback
  • Taking responsibility for mistakes and learning from them
  • Prioritizing the long-term health of the team and project
  • Writing clear, maintainable, and documented code
  • Reviewing code objectively, not personally

Unacceptable Behavior​

The following are not tolerated:

  • Harassment or discrimination of any kind
  • Sexualized language or imagery
  • Trolling, personal attacks, or derogatory comments
  • Publishing private information without permission
  • Aggressive or hostile communication
  • Repeated architectural violations after review feedback
  • Intentionally introducing insecure or unstable code

Enforcement Responsibilities​

Project maintainers are responsible for:

  • Clarifying and enforcing these standards
  • Taking fair and appropriate corrective action
  • Removing contributions that violate this code
  • Communicating moderation decisions when appropriate

Reporting Violations​

Report unacceptable behavior to:

tadreeblms@gmail.com

All reports will be handled confidentially and fairly.

Enforcement Ladder​

  1. Correction -- Private warning and clarification
  2. Warning -- Formal notice with consequences
  3. Temporary Ban -- Restricted participation
  4. Permanent Ban -- Removal from the project

Part 2: Engineering Standards (Laravel 12)

Core Engineering Principles​

We build software that is:

  • Readable
  • Scalable
  • Secure
  • Testable
  • Production-ready

We follow:

  • Thin Controllers, Fat Services
  • Strict typing everywhere
  • No business logic in Blade
  • DRY (Don't Repeat Yourself)
  • Small, focused methods
  • Descriptive naming
  • Always validate input
  • Always eager load relationships
  • Write code for the next developer

Project Structure​

app/ ├── Actions/ ├── Services/ ├── Repositories/ ├── DTOs/ ├── Enums/ ├── Policies/ ├── Http/ │ ├── Controllers/ │ ├── Requests/ │ ├── Resources/

Rules:

  • One class per file
  • Namespace must match folder structure
  • No business logic inside Controllers

PHP Standards​

  • Follow PSR-12
  • Follow PSR-4 autoloading
  • Use Laravel Pint
  • Run before commit:
<!-- -->

./vendor/bin/pint

Strict Types​

Every PHP file must start with:

declare(strict_types=1);

All methods must define:

  • Parameter types
  • Return types

Example:

public function create(array $data): User

Naming Conventions​

Classes:

  • PascalCase
  • Singular
  • Example: UserController, OrderService

Methods:

  • camelCase
  • Verb-based
  • Example: createUser(), processPayment()

Variables:

  • camelCase
  • Meaningful names
  • Avoid: $data, $val, $temp

Controller Rules​

Controllers must:

  • Handle only HTTP concerns
  • Delegate logic to Services or Actions
  • Use Form Requests for validation

Never:

User::create($request->all());

Always:

$this->userService->create($request->validated());

Validation Rules​

  • Always use Form Requests
  • Never validate inside controllers
  • Never trust user input

Generate:

php artisan make:request StoreUserRequest

Eloquent Standards​

  • Always define $fillable
  • Always define relationships
  • Always eager load relationships
  • Avoid N+1 queries

Example:

User::with('orders')->paginate();

API Standards​

  • Use API Resources
  • Use correct HTTP status codes
  • Never return raw models
  • Version APIs when required

Example:

return new UserResource($user);

Logging & Error Handling​

  • Use structured logging
  • Avoid generic logs
  • Create custom exceptions
  • Handle exceptions centrally

Example:

Log::info('User created', ['user_id' => $user->id]);

Security Rules (Mandatory)​

  • Use $fillable
  • Never use $request->all()
  • Use Policies & Gates
  • Escape Blade output
  • Use HTTPS in production
  • No secrets in code
  • No hardcoded credentials

Testing Standards​

Required:

  • Feature tests for endpoints
  • Unit tests for services
  • Use factories
  • Use DB transactions in tests

Minimum requirement:

  • Critical business logic must be tested

Git & Branching Rules​

Branch naming:

  • feature/short-description
  • fix/short-description
  • refactor/short-description

Rules:

  • No direct push to main
  • PR required for merge
  • At least one approval required
  • Resolve conflicts before review

Pull Request Checklist​

Before creating PR:

  • Code formatted with Pint
  • No debug code (dd, dump)
  • No commented dead code
  • Tests written (if required)
  • No N+1 issues
  • No hardcoded values

Definition of Done​

A task is complete when:

  • Code follows standards
  • Tests pass
  • Code reviewed and approved
  • No linting errors
  • No security risks introduced
  • Proper documentation added

Prohibited Practices​

The following are NOT allowed:

  • Business logic in Blade
  • Fat controllers
  • Using $request->all()
  • Unvalidated input
  • Hardcoded credentials
  • Ignoring N+1 issues
  • Committing unformatted code
  • Bypassing code review

Continuous Improvement​

This document is a living standard.

Team members are encouraged to:

  • Suggest improvements
  • Propose architectural refinements
  • Raise scalability concerns early
  • Share performance optimizations

We optimize for long-term maintainability over short-term speed.