Respect/project-info

the RSC applying PSR-1 and PSR-2

henriquemoody opened this issue · 1 comments

henriquemoody commented

The fig Proposed Standards Recommendations had foresight to leave room and flexibility enough so that we may foster our unique style and identity without compromising simplified interoperability and reduced cognitive friction.

This is an attempt at defining how we aim to apply these recommendations influenced by the common denominators evident to date, the product of practicing our credos of allowing PHP to run its natural course while tapping the flexibility and power it unleashes when used as intended. This can henceforth be considered the Respect Syntax Convention or RSC (marked such at specific deviation to the standard fig paths where such deviation is permitted):

You are encouraged to speak up if you have concerns or anything to add. Contrary to urban practice this will not be a vehicle for discourse as it does not factor in new development and code additions at all, no matter it relates to new features, enhancements, crucial bug fixes or a simple proof of concept. You as developer may always enjoy the freedom of your artistic expression while we pave the way to yet another WOW. Instead this would be applied as a product of code review, testing and equal opportunity for our ever growing community to get involved and submit pull request as new adopters experience the code. Similar to the corrections applied to typos and grammar mistakes in our documentation the RSC also aims to facilitate better understanding, unity, commonality and the overall increase of product quality through excellence.

Respect Syntax Convention (RSC)

  • PSR-1 basic-coding-standard (non-negotiable)
    • only use <?php tags
    • Encoding UTF-8 no BOM
    • No side effects
    • Naming conventions - starts with character not _
      • class, interface, trait names StudlyCase - no type prefixing ie IAmInterface
      • Constants UPPER_CASE_UNDERSCORE
      • anything else camelCaseNames.
  • PSR-2 Coding style (negotiable)
    • whitespace
      • Unix LF line ending
      • page width soft limit 120 characters ideal < 80
      • No trailing whitespace, no tabs, use 4 spaces for indent
      • blank line - never more than one
        • as end of file no closing tag ?>
      • after namespace declaration
      • after related block declarations
      • to improve readability
    • keywords, true, false, null in lowercase
    • only one statement per line
    • use block to follow namespace declaration each declaration with it's own use statement no \ prefixing.
    • abstract class interface extends implements (where applicable) on the same line
    • opening and closing braces on their own line
    • comma separated lists, space after comma, on same line within page width or each item on its own line indented once starting with the first item followed only by , (where allowed) or ; (where appropriate) ie.
      • implements,
      • arguments,
      • parameters,
      • elements;
    • Property declaration comma delimited on separate line grouped by scope declaration in the order private, protected, public (RSC)
    • abstract method declaration block follows property declarations in the order protected, public
    • where implemented __construct is the first method declared, followed by other __magic methods first then, followed by normal methods in any scope order
    • no space between method name and opening bracket when declaring or calling
    • opening and closing braces on their own line
    • all methods must have visibility declarations: private, protected, public
    • abstract or final before visibility static thereafter
    • control structures (excluding try catch) are preferably one line nested (without braces) as far as possible (RSC)
    • assignment of variables within brackets where required to avoid wasting a line for assignment
    • conditions must explicitly include comparators when doing assignments in bracket
    • one space before opening and after closing brackets
    • no space after opening and before closing brockets
    • opening brace on the same line as the structure keyword
    • closing brace on it's own line except where else, elseif (don't use else if), while (do while) or catch (try catch)
    • structure body indented once
    • multiple conditions use || and && padded with spaces, when longer than page width new line indent once starting with || or && where possible

to be continued...

Edit: nickl-

henriquemoody commented

According to the latest events I think we are on track of using the FIG standards.

I'm closing this.