PHP e best practices

[lnessuno]

In questi giorni sto iniziando ad intravedere la fine di un grosso progetto e, come sempre in questa fase, mi dedico alla pulizia del codice. Scrivo già seguendo in modo più o meno stretto le convenzioni PSR1 e PSR2 (anche grazie a qualche linter che mi aiuta in questo), ma oggi ho scoperto l'esistenza di PHPMD, cioè PHP Mess Detector. Pare sia uno strumento piuttosto conosciuto, ma non da me

Insomma provo a fare un controllo anche con questo e mi trovo una marea di segnalazioni su best practices che non sto rispettando:

S'incazza ad esempio perché in alcuni casi uso nomi di variabili troppo corte ($id, secondo lui una variabile dovrebbe essere di almeno 3 caratteri)
Poi mi s'incazza perché nelle condizioni faccio uso di else, sostenendo che si può tranquillamente farne a meno e che non si dovrebbero mai usare
Eccetera.


Prima di buttare al vento PHPMD, che TEORICAMENTE sembrerebbe un bello strumento scritto da gente "che ne sa" per aiutare a mantenere il codice pulito e ben organizzato, qualcuno mi sa dire perché diavolo un else potrebbe essere considerato bad practice?

[Alhazred]

In realtà penso che non sia sempre vero, lo è se puoi usare un return.
Esempio stupido in cui si può, se una funzione deve restituire una stringa in base al parametro ricevuto, un if/else sarebbe

function stampa_testo($param)
{
    if ( $param == TRUE )
    {
        return "Param è TRUE";
    }
    else
    {
        return "Param è FALSE";
    }
}

echo stampa_testo(TRUE); 

Ma si può riscrivere senza l'else così

function stampa_testo($param)
{
    if ( $param == TRUE )
    {
        return "Param è TRUE";
    }
    
    return "Param è FALSE";
}

echo stampa_testo(TRUE); 

Questo perché se è TRUE, si entra nell'if e lì finisce, l'ultima istruzione non viene eseguita, se invece è FALSE non si entra nell'if e si esegue solo l'ultima istruzione.

Ma per esempio in questo caso non si può fare a meno dell'else (altro esempio stupido)

// ... del codice ...

if ( $var1 == TRUE )
{
    $pippo = "qualcosa";
}
else
{
    $pippo = "qualcos'altro";
}

// e qui devi andare avanti col codice, quindi nell'if non puoi mettere
// un return e non puoi omettere l'else, altrimenti la relativa istruzione
// viene sempre eseguita anche quando non dovrebbe 

[lnessuno]

Ok su quello sono d'accordissimo... Quello che mi lascia perplesso è la loro spiegazione:

An if expression with an else branch is never necessary. You can rewrite the conditions in a way that the else is not necessary and the code becomes simpler to read.

Ma se per esempio non devo semplicemente fare un return ma assegnare valori diversi a più variabili a seconda di una condizione if?

[Al_katraz984]

secondo me non fossilizzarti troppo sulle indicazioni

alcune sono importanti, ad esempio l'uso degli spazi al posto della tabulazione, ma altre, tipo le parentesi, io non le metto in una nuova linea

if ( $miao == $bau ) {
  echo "Ciao";
  } else {
  echo "Hello";
} 

bello

if ( $miao == $bau ) 
{
  echo "Ciao";
}
else
 {
  echo "Hello";
} 

brutto

Ma se per esempio non devo semplicemente fare un return ma assegnare valori diversi a più variabili a seconda di una condizione if?

senza usare un else:

public function add( $arg, $met, $valid=TRUE ) {
  $this->arg = $arg;
  $this->met = $met;

  $if ( !$valid ) {
    $this->met = $met*count($args);
  }
} 

qui $valid può essere solamente TRUE o FALSE quindi puoi scrivere l'impostazione base e sfruttare un if per una impostazione particolare senza else.

[lnessuno]

... cut ...

Beh, secondo le best practices il tuo codice "ripulito" secondo le convenzioni suggerite da PHPMD (e psr2) dovrebbe essere così:

// le parentesi per classi e funzioni vanno messe su una nuova
    public function add($arg, $met, $valid = true) 
    {
        $this->arg = $arg;
        $this->met = $met;

  // le parentesi per le condizioni vanno sulla stessa linea, senza spazi fra le tonde
        if (!$valid) {
            $this->met = $met*count($arg);
        }
    }

E ci sarebbe ancora un errore concettuale, perchè "The method add has a boolean flag argument $valid, which is a certain sign of a Single Responsibility Principle violation"

Un'altra cosa che fino a ieri non sapevo è che i nomi delle funzioni protette non vanno assolutamente preceduti da un _. In JavaScript quel carattere serve per indicare la visibilità della funzione mentre in PHP la distinzione deve avvenire solo ed esclusivamente dalla dichiarazione public, protected o private. Avendo iniziato qualche tempo fa a lavorare con node.js mi sono abituato a quel carattere e lo trovo più immediatamente visibile. Così me lo sono portato dietro su PHP ed ho scoperto di aver fatto male

Comunque devo dire che a parte alcuni consigli che trovo di difficile attuazione (tipo l'else, che in molti casi si può effettivamente evitare ma in altri non vedo come potrei farne a meno senza complicare ulteriormente il codice), in generale avere uno standard di programmazione aiuta molto, sia a livello di pulizia che per evitare potenziali problemi...

[Al_katraz984]

se ti dice che alla fine del file ci deve essere una riga vuota, butta via PHPMD

<?php
class {


}

?>

la riga vuota se invio degli headers mi frega, altro discorso se ti dicono di non usare il tag di chiusura ma anche li.. non so quanto best practice si possa considerare.
Il _ sulle proprietà protette nun se po' vedere!!
Per la questione delle parentesi preferisco avere un file più compatto che uno espanso e lungo ma sono gusti personali come gli spazi sulle parentesi tonde

[lnessuno]

In effetti anche il tag di chiusura è considerato bad practice dallo standard PSR-2

"A closing tag is not permitted at the end of a PHP file"
http://www.php-fig.org/psr/psr-2/it/

Ovviamente il discorso non vale per i template o dovunque il codice html sia mischiato a php...

[Alhazred]

...

if ( $miao == $bau ) 
{
  echo "Ciao";
}
else
 {
  echo "Hello";
} 

brutto

...

E sarai bello tu

Io le graffe aperte le metto tutte a capo perché mi resta più facile controllare la coppia trovandosi sulla stessa colonna.

Oltre allo spazio tra le parentesi, per miglior lettura metto anche lo spazio dopo il ! quando devo negare una variabile, tipo
if ( ! $var )

secondo me tutte queste cose hanno poco a che vedere con le best practice, è solo questione di gusti personali come giustamente già fatto notare.