Argomenti per la conformità a PSR-2

Question

Argomenti per la conformità a PSR-2

#1 da (3 voti)
#2 da (1 voti)

3

Sto cercando di convincere lo sviluppatore principale di un progetto open source a cui sto contribuendo, per conformarmi agli standard PSR (PSR-2 in particolare) creato dal PHP Framework Interop Group .

È disposto ad adottare PSR-0 e PSR-1, ma è contrario a PSR-2. Il suo argomento è che PSR-2 è troppo incoerente: l'apertura di parentesi graffe per le classi e i metodi DEVE andare alla riga successiva, ma l'apertura delle parentesi graffe per le strutture di controllo DEVE andare sulla stessa linea.

Credo che la differenza tra classi / metodi da un lato e strutture di controllo dall'altro non sia un'incongruenza, in realtà sono cose diverse. Credo anche che la coerenza tra i diversi progetti sia molto più importante del trattare classi / metodi e strutture di controllo come se fossero gli stessi, e che la coerenza tra i progetti dovrebbe prevalere sulle preferenze personali ... ma non riesco a convincerlo.

Ci sono altri argomenti che posso usare per cercare di convincerlo a usare PSR-2, invece di un separato, ancora-un altro standard di codifica?

coding-style coding-standards php

posta Nic Wortel 23.09.2013 - 14:46

fonte

2 risposte

1

Davvero dispiaciuto, ma penso che probabilmente stai perdendo terreno su questo. Gli standard di codifica sono ottimi, ma l'unico standard di codifica che vale lo spazio su disco sul server di progetto è quello che viene effettivamente applicato dallo sviluppatore principale durante le revisioni del codice.

Ciò che il tuo sviluppatore principale sta probabilmente dicendo (ma in parole diverse) è che non vuole passare il tempo nelle revisioni del codice dicendo che la coppia è nel posto sbagliato, e quindi dover giustificarla quando gli altri sviluppatori inizia a borbottare sulla sua meschinità.

risposta data 23.09.2013 - 14:56

fonte

Leggi altre domande sui tag coding-style coding-standards php

Partizionare il codice negli assiemi per motivi di separazione logica L'impostazione di una funzione pubblica influisce sulla capacità del compilatore C # di integrare la funzione come ottimizzazione?

score 3 · Accepted Answer

C'è una differenza tra uno standard esistente e uno standard adottato.

Gli standard vengono adottati solo quando si verifica uno o entrambi i seguenti eventi:

Lo standard ha senso e fornisce più valore al progetto che i "costi" sostenuti dal conformarsi allo standard. Tieni presente che i costi possono richiedere una varietà di moduli, compreso il tempo trascorso in conformità.
Esiste un corpo standard con una leva sufficiente da costringere gli altri a conformarsi allo standard per poter partecipare al dominio. Le specifiche hardware sono buoni esempi di questo scenario.

A quanto pare, non hai nessuno di quei casi che si verificano con il tuo progetto.

Gli standard "Yet-another-standard" si verificano in situazioni esattamente come questa. Se una parte, ma non la totalità, di uno standard ha senso, allora i partecipanti al dominio selezionano le parti che preferiscono e poi avvolgono qualsiasi altra cosa intorno a riempire gli spazi vuoti. Gli standard de facto vengono spesso creati in questo modo e, se guardi all'evoluzione dello standard SQL, vedrai numerose situazioni in cui i partecipanti del dominio hanno spinto l'evoluzione dello standard successivo sulla base della funzionalità che avevano già fornito.

Sembra che tu abbia un in-road con PSR-0 e PSR-1. Inizia con quelli.

Gestisci l'organizzazione responsabile per PSR-2 e fagli sapere perché il tuo progetto non lo sta ancora adottando. (Buono) I corpi degli standard non esistono nei vuoti e apprezzano i feedback dal dominio. Forse sarai in grado di influenzare PSR-3 e renderlo un po 'più appetibile per la tua squadra.