savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[savannah-help-public] [sr #109711] PHP code style of savane


From: Peter Liscovius
Subject: [savannah-help-public] [sr #109711] PHP code style of savane
Date: Wed, 19 Jun 2019 15:02:39 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:67.0) Gecko/20100101 Firefox/67.0

URL:
  <https://savannah.nongnu.org/support/?109711>

                 Summary: PHP code style of savane
                 Project: Savannah Administration
            Submitted by: peterdd
            Submitted on: Wed 19 Jun 2019 09:02:37 PM CEST
                Category: Savannah website
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
             Assigned to: None
        Originator Email: 
        Operating System: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Coding styles are different between programming languages, different between
companies, also different between communities of a programming language by
countries sometimes, and even change over time.

Netherless I want to point out some rules that SHOULD be applied to the PHP
code of savane when changing a file or writing a new .php file:

* Do not put any spaces between a function call and the opening parenthesis.
  It makes reading and searching sourcetrees easier (a grep -rin 'time(' would
not match 'Time to say goodbye.', but any variant of time( Time( tIME( ... 

This was the vote result for PSR-2:


function_space_after:
    no: 22


Clearly.

* Always put the body following an *if* structure within curly brackets, even
if it just contains a single expression!
  Not putting curly brackets there is like laying hidden mines and provokes
hard to find bugs for any later person.
  I don't know why people still keep doing that evil shortcut. Maybe it is
from C-coders that used it 40 years ago to optimize their compiler that
couldn't optimize {} out when a single command follows? I don't know.

There is https://www.php.net/manual/en/control-structures.if.php , but that
guys are C-coders too. 
  For single expression if's there is the ternary conditional operator (but I
find it easier write and read read 'if ($x){ expression } else { expression }'
constructs) 
  'if ($x) ? expression : expression;'

This was the vote result for PSR-2:

+verbstim+
always_use_control_braces:
    no: 3
    yes: 19


Quite clearly.

* Please optionally put . in PHP comments only if it is *a full sentence*. I
even prefer not to put a . even for a single sentense in comment, but that is
not important.

* Do not indent curly brackets at nowhere spaces. Either align it 
  * vertical with the if/while/switch/for/..  
  * opening curly bracket at same line, ending bracket vertical aligned with
if/while/switch/for(...

The other whole bunch of coding styles are debatable, but these 4 are IMHO
important to follow.

General:

* Only change code that matches the commit message. Stick to an existing
coding style of a file. Keeps the changes to git commits small and makes
reviews/git history/git blame/ easier.

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

There is also PSR-2 https://www.php-fig.org/psr/psr-2/, but I would not fully
agree to that standard (See the quite diverting voting results at
https://www.php-fig.org/psr/psr-2/#a1-survey-data 
https://www.php-fig.org/psr/psr-2/

I disagree to that PSR-2 rule:

-verbatim+
indent_type:
    tab: 7 (I prefer this as a user of also dumb/basic editors, navigation
easier)
    2 spaces: 1
    4 spaces: 14


The other rules of PSR-2 are either ok or I do not care of the flavor and can
adapt to it.





    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/support/?109711>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]