Coding Standards

robertdown wrote on Sunday, June 01, 2014:

Coding standards are common place amongst large projects. In my research I haven’t found an “official” coding standard in the OpenEMR project. I’d like to propose that OpenEMR follows the PEAR Coding Standard (Found at http://pear.php.net/manual/en/standards.php). The big notes are:

  • “Indent” = 4 spaces, NO tabs.
  • Lines shall not be longer than 85 characters long (It’s not arbitrary http://paul-m-jones.com/archives/276)
  • Control statements (if, for, while, switch, etc) should have 1 space between control keyword and opening parenthesis.
    • Curly braces (or the : endif; syntax) is always recommended, even if technically optional.
  • Long lines get split
    • Operator at beginning
    • Also applies to ternary operators
  • Function calls
    • NO space between function name, first parenthesis and first parameter.
    • NO space between last parameter, closing parenthesis and semicolon.
    • One space between equals sign and function name if return value is assigned to variable.
    • To support readability, parameters in subsequent calls to the same function/method may be aligned by parameter name
    • Split parameters to multiple lines if function call will take more than 80 characters (Character limit > keeping function on 1 line)
      • Parameters are given 4 spaces from left flush of function call
      • Closing parenthesis and semicolon are on separate line matching left indent of initial function call line.
        • Same applies to nested function calls and arrays
  • Equal signs may be aligned to support readability
    • The rule can be broken when the length of the variable name is at least 8 characters longer/shorter than the previous one:
    • Assignments may be split onto several lines when the character/line limit would be exceeded. The equal sign has to be positioned onto the following line, and indented by 4 characters.

There are plenty more rules, too much to “summarize”

A tool exists called “PHP Code Sniffer” and can be installed through PEAR. It is similar to PHPUnit - You define the standard (The PEAR coding standard comes “in the box” with PHPCS) and you get a report indicating errors and warnings.

I propose that new code follow this standard, and any refactored code follows the standard as well.

bradymiller wrote on Sunday, June 01, 2014:

Hi Robert,

Check out this page on the wiki:
http://www.open-emr.org/wiki/index.php/Development_Policies

And feel free to work your above stuff in (perhaps a new section with summary, plan and PEAR discussion and tool).

During reviews, it can be tough to force a bunch of this stuff while ensuring the coding(much easier when have a link to specific requirements on the wiki) is OpenEMR friendly at the same time. But agree we should be shooting for this on all new scripts (for scripts that already exist, I generally just request developers to follow formatting of the current script). If a user decided to refactor(ie. clean up) a page, I’d suggest doing only the refactor and nothing else (for example, if making coding changes also to a script then do this in another commit) so it’s clear what coding is being changed.

-brady
OpenEMR