Può esserci troppa uniformità negli standard di codifica?

12

Esiste troppa uniformità? Ovviamente, dove lavoro, abbiamo standard che includono convenzioni di denominazione, architetture, strutture da sfruttare, ecc. Tuttavia ultimamente ci sono state molte critiche su cose che considererei più stile.

Ad esempio, scrivere ifistruzioni in più righe rispetto a una riga, utilizzando l' ??operatore c # null coalescing anziché dire == null, quantità di spazio per rientri ecc.

Mi sembra che questo inizi ad entrare di più in una scelta di stile personale e non debba essere uniforme in una squadra o azienda. Ciò che una persona pensa legge più chiaramente un'altra potrebbe non esserlo. C'è un valore per questa uniformità "extra"?

programming-practices team coding-standards

— Gratzy
fonte

2

Ciao Gratzy, Programmers.SE non è un forum di discussione ; siamo qui per risolvere i problemi reali che potresti incontrare. Hai un problema reale che stai cercando di risolvere? In tal caso, puoi riformulare la tua domanda per mantenere le risposte costruttive e fuori dalle insidie di diventare una discussione?

1

@Gratzy per dirla in altro modo, data una situazione che stai affrontando personalmente, quali sarebbero i criteri per una risposta corretta?

2

@Mark Trapp secondo le FAQ questi sono i criteri per una domanda Tutte le domande soggettive dovrebbero essere costruttive. Come lo definiamo? Domande soggettive costruttive ... 1. ispirare risposte che spieghino "perché" e "come". 2. tendono ad avere risposte lunghe, non brevi. 3. avere un tono costruttivo, giusto e imparziale. 4. invita a condividere esperienze e opinioni. 5. insistono affinché si sostenga l'opinione con fatti e riferimenti. 6. sono molto più di un semplice divertimento sociale senza cervello. Credo che la mia domanda

— riguardi

2

@Gratzy anche dalle FAQ: "Dovresti solo porre domande pratiche e rispondenti in base ai problemi reali che affronti. Le domande chiacchierate e aperte riducono l'utilità del nostro sito e spingono altre domande dalla prima pagina."

2

@Mark Trapp Ho già dichiarato i criteri per una risposta accettabile e sì, come ho già detto, questo è un problema reale e francamente dall'interesse per la domanda e le risposte che direi che gli altri sono d'accordo.

— Gratzy,

16

L'uniformità non è un problema (va bene) ma può essere rigidità o inflessibilità . Se nella lotta per l'uniformità diventi dogmatico, il danno che stai facendo alla squadra potrebbe essere maggiore del bene che deriva dall'uniformità (forse) risultante.

È meglio solo impostare lo stile di base per le cose più importanti (standard di denominazione e capitalizzazione, rientro, nuove righe e posizionamento delle parentesi, ecc.), Impostare raccomandazioni per cose meno importanti (se il formato dell'istruzione, altri spazi bianchi attorno alle parentesi, ecc.) e quindi non preoccuparti per il resto.

— Nicole
fonte

1

Ci sono stato

+1, ha detto cosa volevo dire, ma meglio!

— FrustratedWithFormsDesigner

@Pierre è questo il motivo per cui sei un freelance adesso? :)

— Nicole,

non proprio, ma ho incontrato alcune persone ossessive sulle linee guida. È spaventoso come possa essere estremo. Penso che tu abbia definito abbastanza bene il limite.

7

Quando potenzialmente decine di persone stanno lavorando a un progetto nel corso degli anni della sua durata di vita, a volte diventa confuso quando devi saltare gli stili. Immagina di leggere un libro in cui diversi capitoli sono scritti da autori diversi che mantengono solo un po 'lo stile di scrittura. È possibile, ma è fastidioso.

La maggior parte degli IDE può applicare gli stili in questi giorni, quindi se necessario è possibile distribuire (come parte del codice sorgente del progetto) un file delle preferenze IDE che specifica lo stile di codifica scelto e che tutti lo installino e lo utilizzino per formattare il codice che stanno scrivendo . Scommetto che ci sono anche modi per riformattare / definire il codice al check-in (anche se non ho ancora dovuto indagare su questo).

— FrustratedWithFormsDesigner
fonte

Sì, probabilmente potresti attaccare un copione di formica lì da qualche parte.

— Michael K,

1

IntelliJ, almeno, ha un'opzione per riformattare il codice prima del check-in.

— Nicole,

3

Un caso di over-uniformity che ho visto è quello di avere un unico standard che si applica a tutti i linguaggi di programmazione indipendentemente dall'adeguatezza:

Scoraggiando gotoanche in linguaggi come C senza try... catch.
Utilizzo dei InitialCapsnomi (come in Microsoft MFC e C #) in JavaScript in cui si trova la libreria standard initialLowerCase.

— dan04
fonte

2

Non penso che esista troppa uniformità. Tuttavia, trovo spesso troppa SPECIFICITÀ negli standard di codifica. I vantaggi di tutti mettere la parentesi graffa di apertura su una linea separata sono nella migliore delle ipotesi dubbi e non superano il tempo trascorso a discuterne o a risolvere problemi estetici nel codice.

— JohnFx
fonte

2

@Tungano Non potrei essere più d'accordo. Il paradosso degli standard di codifica è che vale la pena avere, ma non vale la pena discutere.

— Charles E. Grant,

3

Non vedo come forzare uno stile particolare nella gola di un programmatore ti aiuterà ad evitare quegli argomenti. In effetti, direi che fare in modo che un programmatore si adatti ad uno stile che non gradisce INCORAGGIA quegli argomenti, o almeno risentimento.

— JohnFx,

1

@JohnFx, perché la maggior parte dei programmatori si renderà conto che la coerenza dello stile offre un contributo molto più grande alla qualità del codice e alla manutenibilità rispetto a qualsiasi particolare scelta di stile. Nella mia esperienza puoi fare un rapido conteggio del naso della squadra, vedere cosa piace e cosa non piace alla gente e rapidamente raggiungere un consenso. Occasionalmente qualcuno avrà un bugaboo particolare e tu li accontenterai, quindi cederanno al bugaboo di qualcun altro. Se mi trovo a maledire la squadra per cinque minuti sul perché il caso dei cammelli è malvagio, mi arrendo e cedo come prova della mia flessibilità personale.

— Charles E. Grant,

1

Direi che la maggior parte dei programmatori PENSA che la coerenza dello stile offra un contributo così grande, ma in realtà non lo è. Sembra che dovrebbe, è fastidioso guardare un codice che non corrisponde allo stile del tuo animale domestico, e passare attraverso un blocco di codice "ripulendolo" per problemi estetici minori è un buon modo per procrastinare. Senti, ero anche su quel carrozzone fino a quando mi sono reso conto che mi stavo concentrando sulla doratura e non sul risultato.

— JohnFx,

1

Lavoro con il codice del nostro team tedesco, un paio di progetti OSS e alcuni codici antichi che abbiamo, così come le nostre cose attuali. Alcuni sono C, altri C ++, altri C #. Quindi devo lavorare con diversi stili di codice diversi in ogni momento. Quando lo fai, ti rendi conto di quanto siano meschine le linee guida di stile che sono obbligate negli standard. Se riesco a passare da un progetto a un altro, posso gestire qualcuno che mette il suo {} in luoghi diversi. Questo è il motivo per cui penso che l'unico standard degno di nota sia quello con 1 regola: "coerenza all'interno di ciascun progetto".

— gbjbaanb,

2

Avrei 2 argomenti per l'uniformità:

Promuovere la proprietà collettiva. Che qualcuno possa andare a modificare il codice di qualcun altro senza temere che il "bambino" di qualcuno stia per essere danneggiato dal cambiamento. Una sorta di mentalità "Siamo tutti insieme".
Facile da aggiungere ad esso. Se qualcosa è già stato fatto da qualche altra parte, questo può essere preso e riutilizzato possibilmente. Alcune convenzioni possono aiutare a rendere le cose più facili da leggere o modificare a volte, quindi questo è un altro vantaggio per la mia mente.

— JB King
fonte