Perché il codice Wordpress è così "felice nello spazio"?

Il core WP, molti plugin WP e gli stessi standard di codifica WP usano un'applicazione "generosa" del Spacepersonaggio (non per indentazione, ma "dentro" di parentesi e parentesi). Questo sembra essere unico per Wordpress - questo stile / filosofia non sembra essere presente in altri progetti simili, PHP o altro.

Per ulteriori informazioni su questo approccio, consultare: https://make.wordpress.org/core/handbook/coding-standards/php/#space-usage

Esempio: foreach ( (array) $foo as $bar ) { ...

Mi riferisco allo spazio dopo foreach, dopo il primo (e prima del finale )(e altri spazi simili mostrati in "Space Usage" al link sopra).

Questo stile mi sembra superfluo - richiede una maggiore digitazione e (opinione) rende l'analisi del codice visivamente più difficile. (/ Opinione)

Il mio desiderio non è di discutere se questo stile sia o meno una buona idea. Piuttosto, voglio semplicemente capire i motivi per cui questo è lo stile raccomandato. Anche i commentatori sugli standard di codifica WP sono curiosi:

inserisci qui la descrizione dell'immagine

Le risposte fornite alla domanda di MK Safi sono essenzialmente:

Per leggibilità
Status quo (noto anche come "Così è")

Il mio ragionamento per chiedermi è che personalmente non vedo molto valore nell'adottare gli standard di codifica WP (per quanto riguarda lo "Uso dello spazio") nei nostri progetti esclusivamente interni. Tuttavia, sono curioso di sapere se mi manca qualcosa.

Ci sono ragioni al di là delle due sopra elencate, apparentemente valide o no, per seguire lo stile "Space Usage" di Wordpress?

coding-standards

— rinogo
fonte

Puoi fare quello che ti piace sui tuoi progetti interni, purché tu sia coerente. Come nota a margine, utilizziamo le tabulazioni anziché gli spazi, quindi discutibilmente richiediamo meno digitazione, non che questo sia in alcun modo se hai un IDE moderno che fa tutta la formattazione per te e puoi riformattare in stili diversi per te (ad esempio sublime con pacchetti, PHPStorm, ecc.)

— Tom J Nowell

Grazie per il tuo commento, @ TomJNowell! Penso che forse ho comunicato male la mia "domanda" - sto chiedendo di meno sulle schede / spazi per il rientro, e di più sulle regole menzionate sotto "Uso dello spazio" su make.wordpress.org/core/handbook/coding-standards/php /… . Scusa non sono stato più chiaro!

— Rinogo,

È più facile da leggere quando non si ha l'evidenziazione della sintassi. Questo è almeno il motivo per cui sto usando quello stile nei progetti interni. Devo modificare PHP spesso in una console semplice con vi in una configurazione minima.

— fuxia

FWIW, MediaWiki ha una convenzione di stile molto simile ed è in realtà piuttosto severa nel farla rispettare (almeno nel nucleo). Hanno anche uno script per l'aggiunta automatica di spazi mancanti. Tutto quello che posso dire è che ci si abitua dopo un po '.

— Ilmari Karonen,

@rinogo Lo so, i commenti a volte sono solo commenti, non risposte :)

— Tom J Nowell

Risposte:

Resoning

Per quanto riguarda lo "spazio bianco" (non importa se le schede o gli spazi): è semplicemente una preferenza personale che è rimasta fedele al progetto.

Le norme di codifica WP imo sono un disastro e possono essere ignorate - purché non contribuiate al core, che è

una storia diversa e
la guida di stile viene ignorata anche lì.

"[...] non viene applicato retroattivamente in blocco su codice più vecchio in quanto rende la cronologia svn / git molto difficile da usare. La politica ufficiale è che il nuovo codice dovrebbe seguire la guida di stile, ma se ti capita di formattare correttamente il codice adiacente così sia, ma le patch che formattano solo il codice o commettono che è proibito solo il codice di formattazione ".

^{- @TomJNowell nei commenti}

alternative

Stai meglio attenendoti agli standard PSR (vale a dire: 2) o cose come gli standard Symfony (o solo i tuoi).

Aumento delle prestazioni e strumenti

Non si ottiene alcun profitto dall'avere uno standard di codifica (oltre ad averne uno da condividere e la minoranza che lo odia, mentre il resto lo impone) o dall'avere più o meno schede o spazi. Nel caso in cui tu sia preoccupato per lo spazio su disco non necessario utilizzato o forse per i programmi più lenti, puoi comunque comprimere il tuo codice (vedi il progetto GitPHPHooks ) su commit. Il vantaggio che otterrai sarà di circa il 5% massimo rispetto allo spazio del file originale, praticamente uguale a quello che ti dà la compressione / minificazione della sintassi HTML. Per questo ci sono strumenti di minimizzazione di Node.js disponibili tramite npm.

Ciò che personalmente ho trovato davvero utile è PHP Linter e _PHP Mess Detector. Ho incorporato entrambi nella Libreria di GitPHPHooks, quindi non devo pensarci o preoccuparmene.

— Kaiser
fonte

La guida di stile non viene ignorata per Core, ma non viene applicata retroattivamente in blocco sul codice precedente poiché rende la cronologia svn / git molto difficile da usare. La politica ufficiale è che il nuovo codice dovrebbe seguire la guida di stile, ma se ti capita di formattare correttamente il codice adiacente, allora così sia, ma le patch che formattano solo il codice o commettono che è proibito solo il codice di formattazione

— Tom J Nowell

@TomJNowell E quindi rende inutile la guida di stile :) In ogni caso, si prega di presentare una modifica e aggiungerla alla risposta. Sono informazioni degne di nota.

— Kaiser

Penso di non essere stato molto chiaro nella mia domanda: mi riferisco meno a tabulazioni vs spazi e più a "Uso dello spazio" su make.wordpress.org/core/handbook/coding-standards/php/… . Modificherò la domanda per essere più chiari.

— Rinogo,

@rinogo Ti ho capito bene la prima volta, da qui il primo paragrafo. A proposito, lo considero anche più leggibile.

— Kaiser,

Gli spazi dopo i punti sono normali, ad esempio $baz . '-5'questo stile viene utilizzato in molti standard di codifica per gli operatori ( y + z).

Questo viene fatto per migliorare la leggibilità, ad esempio uno di questi è più leggibile dell'altro.

$cow.$dog.$cat.$table.$chocolate.$puddle.$iterator.$stuctureone.$stucturetwo

$cow . $dog . $cat . $table . $chocolate . $puddle . $iterator . $stuctureone . $stucturetwo

Ciò diventa ancora più ovvio se circondato da altri "codici".

Per quanto riguarda gli spazi attorno alla parentesi, ( 1, 2, 3 )non ne ho idea, immagino che anche l'argomento riguardi la leggibilità.

Può essere fonte di confusione poiché gli stessi standard di WordPress hanno esempi con parentesi nei commenti che non hanno spazi e il codebase stesso è confuso con alcune parti che hanno spazi e altre no (vedi screenshot sotto) anche all'interno della stessa funzione.

La maggior parte degli standard PHP in realtà fa l'opposto una richiesta di ... le parentesi dovrebbero abbracciare il loro contenuto. In effetti la maggior parte degli standard di codifica per altre lingue lo scrive in questo (1, 2, 3)modo : quindi è un po 'un mistero il motivo per cui WP lo fa in questo modo.

Ecco un esempio per confrontare da una funzione di WordPress.

inserisci qui la descrizione dell'immagine

Versione più grande da confrontare: http://i.imgur.com/nTEbV7v.jpg

Preferisco quello a destra soprattutto quando si guarda a tutto schermo di codice, ma è una preferenza personale.

— Wyck
fonte

grazie per la tua risposta! La .spaziatura ha senso per me, dato che in .realtà è solo un operatore binario, proprio come +o -. Il tuo pensiero sulle parentesi che "abbracciano" il loro contenuto è esattamente il motivo per cui ho posto questa domanda. Questo comportamento, insieme alle regole ancora più strane come quelle per le parentesi quadre (WP dice di usare $foo['bar']e $foo[ $bar ]) sono esattamente il motivo per cui ho posto questa domanda. :)

— rinogo