2010-05-05 17 views
5

Sto cercando di trovare le migliori pratiche per scrivere PHP.PHP e scrittura codice pulito

Mi chiedo solo che sia una cattiva abitudine.

Ad esempio, elaborazione delle variabili.

$var = 1 
$var = doSomething($var); 
$var = doSomething2($var); 
$var = doSomething3($var); 

Sembra un po 'orribile.

Ecco un esempio di un codice reale che ho appena fatto:

$this->rSum = explode(",", $this->options["rSum"]); 
$this->rSum = array_combine(array_values($this->rSum), array_fill(0, count($this->rSum), 0)); 

Se qualcuno potesse passarmi qualche buon tutorial di scrivere codice più pulito in generale sarebbe bello!

Mi fa ancora domande stupide. :)


A proposito ..

Quanto elaborazione automatica può esserci in modelli?

Ho un modello che ha un metodo di esecuzione e quando lo chiamo, fa un sacco di cose come leggere un file di definizione e fare query di database.

Ad esempio

$object = new Object() 
$object->setFile("example.txt"); 
$object->execute(); 

// Then i can fetch things from it 
echo $object->getName(); 

risposta

3

Mi piace molto il tuo codice (reale) ed è solitamente abbastanza difficile per me gradire il codice di altre persone (non ho avuto molto tempo per scavare in ZF ma PEAR ad esempio [hanno anche i loro standard di codifica] è solo IMO terribile), il primo esempio che hai dato sembra solo stupido, ma per quanto riguarda il secondo, è davvero facile da capire almeno per me e dal breve frammento che hai fornito ti sembra di avere uno stile di codifica coerente e di usare gli spazi bianchi nella destra importo e al posto giusto - conta molto per il codice pulito (se non mi credi, dai un'occhiata ai frammenti di Perl).

Vorrei solo far notare tre cose:

  1. Semantica: Anche se rSum non è un nome terribile per una proprietà che non è del tutto chiaro quali valori vuol tenere, forse si potrebbe trovare un nome più descrittivo per quella proprietà?
  2. riutilizzo Variabile: Come ho detto prima il vostro primo esempio sembra stupido, ma in realtà è intelligente di riutilizzare le variabili per due motivi principali:
    1. Non perdi la memoria.
    2. E non inquina l'ambito su cui stai lavorando.
  3. tuo secondo esempio "reale" potrebbe essere più pulito e più veloce se si utilizzano i giusti funzioni:

    $ this-> rsum = array_flip (explode (", " $ this-> Opzioni [" rsum "]));

EDIT: Ho appena notato il codice che ho fornito sopra non è proprio quello che stai facendo (il 0 non è stato elaborato dal mio cervello), qui è un'altra alternativa di lavoro:

$this->rSum = array_fill_keys(explode(",", $this->options["rSum"]), 0); 

Qui sembra che ci siano molte persone che non amano il one-liner, tuttavia, credo che il codice sopra sia chiaro, efficiente e descrittivo, ma potrebbe essere solo io ... =)

8

Il codice smart non è necessariamente un buon codice secondo me. Personalmente preferirei codice pulito, semplice e facile da capire. La tua 2 fodera farà riflettere i tuoi pari, al contrario del tuo codice "cattivo" di init.

Questo è solo il mio prendere comunque

+1

peer, non pera: P – Viet

3

Oltre agli standard di codifica, è possibile utilizzare PHP_CodeSniffer per ottenere suggerimenti generali sul codice esistente.

0

D'accordo con Jim Li, preferisco anche codice leggibile su micro-ottimizzazione o smart ma brutto codice one-liner.

L'unico problema che ho avuto con il primo esempio è che utilizza funzioni procedurali orientate, sarei stato meglio riscritto OOP (chiamate di funzioni come questa potrebbero essere incatenate e rimanere facili da leggere).

PHP non ha un forte obiettivo OOP, poiché utilizza principalmente dichiarazioni procedurali nelle sue API. Ma preferisco scrivere il mio codice in modo OO, ben disaccoppiato e organizzato, piuttosto che avere un sacco di funzioni con un sacco di argomenti per farli lavorare insieme.

-3

One cosa che cerca di fare tutto in uno la linea può portare a supposizioni di codice. Che considero davvero noioso quando devo aggiustarli. Questo è più comune con il concatenamento degli oggetti. Per esempio

$object->getAnotherObject()->getAThirdObject()->doSomething(); 

Un sacco di persone ti diranno che è più facile da leggere; tuttavia si basa su ogni ritorno che è un oggetto ogni volta. Preferisco restituire ciascuno e controllare la risposta.

$secondObject = $object->getAnotherObject(); 
if (is_object($secondObject)) { 
    $thirdObject = $secondObject->getAThirdObject(); 
    if (is_object($thirdObject)) { 
     $thirdObject->doSomething(); 
    } 
} 

Ci vuole più sequenze di tasti certo, ma sarà meno probabilità di far saltare in aria e, credo in ogni caso, più facile da leggere.

Anche se vale la pena ripetere ciò che ha scritto Boris Guéry. essere coerenti.

+0

"Più pulito ?! Più facile da leggere ?!" Interfacce fluide, ad esempio una classe SQL Builder: '$ sql-> select ('posts', 'title') -> where (array ('user_id' => 5)) -> order ('date', 'desc ') -> limit (10); ', con il tuo approccio questo richiederebbe 5 livelli di indentazione inutili perché nelle interfacce fluenti tutti i metodi dovrebbero restituire l'oggetto non importa quale. –

+0

Quando sai cosa sta tornando va bene. Che ne dici di quando salti in un progetto e devi iniziare a capire mentre codifichi? Non puoi basare le cose sugli scenari migliori. Cosa succede se qualcuno aggiorna una parte di un progetto su cui stai lavorando e fa qualcosa restituire una matrice di oggetti? – Khainestar

+0

E la legge di Demeter? –

Problemi correlati