Checklist / Code Review PHP



Utilize the guard clause writing style instead of the traditional if-else approach.

Use Guard Clauses for Cleaner Code

There should be no business logic in the controller (Sanity check okay)

There should be no database code in the service or controller classes

Solid principles: Ensure that the code follows the SOLID principles of object-oriented design, which include Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion principles. These principles promote clean, maintainable, and extensible code.

Type hinting: Use type hints in function and method declarations to specify the expected data types for parameters and return values. Type hinting helps improve code clarity and prevents type-related errors.

TRY CATCH: Implement proper error handling using try-catch blocks. This ensures that exceptions are caught and handled gracefully, preventing crashes and providing meaningful error messages to users or developers.

Properly log exceptions: Log exceptions in a structured and informative way, including the date and time of the exception occurrence, the type of exception, the exception message, the file where it occurred, and the line number. This helps in debugging and tracking issues efficiently.

} catch (Exception $e) { // Log the exception message, filename, and line number $logMessage = "Exception: " . $e->getMessage() . " in " . $e->getFile() . " on line " . $e->getLine() . "\n"; $logMessage .= $e->getTraceAsString(); HelperService::logger('debug',logMessage); // Rethrow the exception if necessary throw $e; }

Example log format: [Date and Time] – [Exception Type]: [Exception Message] in [File] on line [Line Number]


Declare strict_types = 1;: Enable strict typing in PHP by declaring strict_types = 1; at the beginning of your PHP scripts. This ensures that type coercion is disabled and helps prevent unexpected type-related issues.

Functional tests: Develop and perform functional tests for your code to verify that it behaves as expected and meets the specified requirements. Functional tests help ensure the correctness of your code.

PHP Doc: Use PHPDoc comments to provide clear and comprehensive documentation for your code. Include descriptions of functions, methods, classes, and their parameters, return types, and any exceptions they may throw. Well-documented code is easier for others to understand and use.

Validate PSR-2 compliance: Ensure that your code adheres to the PSR-2 coding style standard for PHP. PSR-2 provides guidelines for code formatting, naming conventions, and indentation, promoting consistency and readability across projects.

No PHP error messages: Make sure that there are no PHP error messages in your code. PHP errors can disrupt the functionality of your application and should be addressed and resolved.

No PHP Warning messages: Similarly, ensure that there are no PHP warning messages in your code. Warnings can indicate potential issues that need to be fixed to maintain the stability of your application.

No PHP Notices: Eliminate PHP notices from your code. Notices are typically non-fatal issues, but it’s best to address them to prevent unexpected behavior.

No hardcore credentials: Avoid hardcoding sensitive credentials such as usernames, passwords, or API keys directly into your code. Instead, use secure configuration management practices to store and access these credentials securely. Use feature toggle

Function no longer than 50 lines: Keep individual functions or methods concise and focused, with a maximum of 50 lines of code. This promotes code readability and maintainability by breaking complex logic into smaller, more manageable pieces.

Coding Principles

2 – PHP Docs should mach the following format

/** * Update Shipment Status * * @param string $m2_shipment_uuid * @param string $payload * @return bool * * @throws Exception * Exception('No file requirements',500) * Exception('issue converting artworkinfo into an object',500) * Exception('Artwork info not available for set_uuid :'.$shipment['m2_set_uuid'], 422); * Exception('file_uuid is not present within the artwork info block of set_uuid :'.$shipment['m2_set_uuid'], 422) * * @author David Raleche <[email protected]> * * @since 10-09-2020 * @version 10-28-2020 * * @internal M2-1045 Extend PATCH /v1/m2-shipments/:uuid to validate that files are still available */

@Raman Sobal @Manit Shah @Salvi Pascual @Nurbek Chymbaev

@Kevin Fung@v-johnlee (Unlicensed) add an equivalent in Javascript below

GIT Conflict Steps to FOLLOW

#1 – step – Squash Merge

#2 – in case of Pull Request conflict against DEV environment

(1) clone your branch and rename yourbranch_merge_to_dev_03-22-2022

(2) do a pull request of that branch against DEV

(3) Resolve conflict via UI or via your sandbox

When resolving conflict via sandbox, follow the steps below :

Step 1. git merge dev --no-commit --no-ff

This will bring in changes from dev without merging them

Step 2. Examine the result of step 1 and find the conflict files and fix them locally

Step 3. git commit -am "conflict resolved"

Step 4. git push origin yourbranch_merge_to_dev_03-22-2022

Above steps will avoid bringing in Dev branch changes into your pull request

(4) Squash Merge

#3 – in case of Pull Request conflict against QA environment

(1) clone your branch and rename yourbranch_merge_to_qa_03-22-2022

(2) do a pull request of that branch against QA

(4) Squash Merge

(3) Resolve conflict via UI or via your sandbox

Leave a Reply