Pensi che una società di software dovrebbe imporre agli sviluppatori uno stile di programmazione? [chiuso]

https://stackoverflow.com/questions/145508

02-07-2019
|

Domanda

Se pensi che non dovrebbe, spiega perché.

Se sì, quanto dovrebbero essere profonde le linee guida secondo te? Ad esempio, il rientro del codice dovrebbe essere incluso?

Soluzione

Penso che una squadra (piuttosto che una azienda ) debba concordare una serie di linee guida per uno stile ragionevolmente coerente. Lo rende più semplice per la manutenzione.

Quanto in profondità? Più superficiale che puoi concordare. Più è corto e chiaro, più è probabile che tutti i membri del team possano accettarlo e rispettarlo.

Altri suggerimenti

Volete che tutti leggano e scrivano il codice in modo standard. Esistono due modi per raggiungere questo obiettivo:

Clona più volte un singolo sviluppatore e assicurati che tutti seguano lo stesso addestramento. Eventualmente dovrebbero essere tutti in grado di scrivere la stessa base di codice.
Dai ai tuoi sviluppatori esistenti istruzioni esplicite su ciò di cui hai bisogno. Schede o spazi per il rientro. Dove si trovano le parentesi graffe. Come commentare Linee guida per il commit del controllo versione.

Più lasci indefinito, maggiore è la probabilità che uno degli sviluppatori si scontri sullo stile.

La società dovrebbe imporre che uno stile sia seguito. Qual è lo stile e quanto profonde le linee guida dovrebbero essere decise collettivamente dalla comunità degli sviluppatori all'interno dell'azienda.

Definirei sicuramente le linee guida su parentesi graffe, rientri, denominazioni ecc ... Scrivi il codice per leggibilità e manutenibilità. Supponi sempre che qualcun altro leggerà il tuo codice. Esistono strumenti che formattano magicamente automaticamente il tuo codice e puoi imporre che tutti lo utilizzino.

Se sei su .Net guarda stylecop, fxcop e Resharper

Pensi che una società di software dovrebbe imporre agli sviluppatori uno stile di programmazione?

Non in modo discendente. Gli sviluppatori di una società di software dovrebbero concordare uno stile di codifica comune.

In caso affermativo, quanto dovrebbero essere profonde le linee guida secondo te?

Dovrebbero solo descrivere le differenze rispetto a convenzioni ben note, cercando di mantenere la deviazione minima. Questo è facile per linguaggi come Python o Java, un po 'sfocato per C / C ++ e quasi impossibile per Perl e Ruby.

Ad esempio, il rientro del codice dovrebbe essere incluso?

Sì, rende il codice molto più leggibile. Mantenere il rientro coerente in termini di spazi rispetto alle schede e (se si opta per gli spazi) numero di spazi. Inoltre, concordare un margine (ad esempio 76 caratteri o 120 caratteri) per le linee lunghe.

Sì, ma entro limiti ragionevoli.

Tutti gli IDE moderni offrono il codice one-key pretty-print, quindi " indentation " il punto è abbastanza irrilevante, secondo me.

Ciò che è più importante è stabilire le migliori pratiche: ad esempio, utilizzare come " out " oppure " ref " parametri possibili ... In questo esempio, hai 2 vantaggi: migliora la leggibilità e corregge anche molti errori (molti parametri fuori sono un odore di codice e probabilmente dovrebbero essere sottoposti a refactoring).

Andare oltre questo è, secondo la mia onesta opinione, un po '" anal " e inutilmente fastidioso per gli sviluppatori.

Buon punto di Hamish Smith:

Lo stile è abbastanza diverso dal migliore pratiche. È un peccato che 'codificare gli standard tendono a far rotolare i due insieme. Se le persone potessero mantenere il parte di stile al minimo e concentrarsi sulle migliori pratiche che aggiungerebbe probabilmente più valore.

Non credo che un team di sviluppo debba avere linee guida di stile che deve seguire come regola generale. Ci sono eccezioni, ad esempio l'uso di & Lt; & Gt; vs. " " nelle dichiarazioni #include , ma queste eccezioni dovrebbero venire dalla necessità.

Il motivo più comune che sento le persone usare per spiegare perché sono necessarie le linee guida di stile è che il codice scritto in uno stile comune è più facile da mantenere quel codice scritto nei singoli stili. Non sono d'accordo. Un programmatore professionista non si impantanerà quando vedrà questo:

for( int n = 0; n < 42; ++42 ) {
 // blah
}

... quando sono abituati a vederlo:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

Inoltre, ho scoperto che in alcuni casi è più semplice mantenere il codice se è possibile identificare il programmatore che ha scritto il codice originale semplicemente riconoscendone lo stile. Vai a chiedere loro perché hanno implementato il gizmo in modo così contorto in 10 minuti invece di passare la parte migliore della giornata a capire il motivo molto tecnico per cui hanno fatto qualcosa di inaspettato. È vero, il programmatore avrebbe dovuto commentare il codice per spiegare il loro ragionamento, ma nel mondo reale i programmatori spesso non lo fanno.

Infine, se Joe impiega 10 minuti di backspacing & amp; spostando le parentesi graffe in modo che Bill potesse passare 3 secondi in meno a guardare il codice, è davvero risparmiato tempo per fare in modo che Bill faccia qualcosa che non gli viene naturale?

Credo che avere una base di codice coerente sia importante. Aumenta la manutenibilità del tuo codice ur. Se tutti si aspettano lo stesso tipo di codice, possono facilmente leggerlo e capirlo.

Inoltre non è una seccatura dato gli IDE di oggi e le loro capacità di formattazione automatica.

P.S: Ho questa fastidiosa abitudine di mettere le parentesi graffe sulla riga successiva :). A nessun altro sembra piacere

Penso che i programmatori dovrebbero essere in grado di adattarsi allo stile di altri programmatori. Se un nuovo programmatore non è in grado di adattarsi, di solito significa che il nuovo programmatore è troppo testardo per usare lo stile dell'azienda. Sarebbe bello se tutti potessimo fare le nostre cose; tuttavia, se tutti codifichiamo seguendo alcune linee guida di Bast, ciò semplifica il debug e la manutenzione. Questo è vero solo se lo standard è ben congegnato e non troppo restrittivo.

Anche se non sono d'accordo con tutto, questo libro contiene un eccellente punto di partenza per gli standard

La soluzione migliore sarebbe che gli IDE considerassero tale formattazione come metadati. Ad esempio, la posizione di parentesi graffa aperta (riga corrente o successiva), rientro e spazio bianco attorno agli operatori dovrebbe essere configurabile senza modificare il file di origine.

Secondo me penso che sia altamente necessario con gli standard e le guide di stile. Perché quando la tua base di codice cresce vorrai che sia coerente.

Come nota a margine, ecco perché amo Python; perché impone già molte regole su come strutturare le tue applicazioni e simili. Confrontalo con Perl, Ruby o qualsiasi altra cosa in cui hai un'estrema libertà (che non è così buono in questo caso).

Ci sono molte buone ragioni per cui gli standard definiscono il modo in cui le applicazioni vengono sviluppate e l'aspetto del codice. Ad esempio, quando tutti usano lo stesso standard, è possibile utilizzare un controllo di stile automatico come parte dell'elemento della configurazione del progetto. L'uso degli stessi standard migliora la leggibilità del codice e aiuta a ridurre la tensione tra i membri del team riguardo al re-factoring dello stesso codice in modi diversi. Pertanto:

Tutto il codice sviluppato da un determinato team dovrebbe seguire esattamente lo stesso standard.
Tutto il codice sviluppato per un particolare progetto dovrebbe seguire esattamente lo stesso standard.
È auspicabile che i team appartenenti alla stessa azienda utilizzino lo stesso standard.

In una società di outsourcing potrebbe essere fatta un'eccezione per un team che lavora per un cliente se il cliente vuole imporre uno standard proprio. In questo caso il team adotta lo standard del cliente che potrebbe essere incompatibile con quello utilizzato dalla propria azienda.

Come altri hanno già detto, penso che debba essere affidato all'ingegneria o al team: la società (ovvero le unità aziendali) non dovrebbe essere coinvolta in questo tipo di decisione.

Ma un'altra cosa che aggiungerei è che tutte le regole implementate dovrebbero essere applicate dagli strumenti e non dalle persone. Lo scenario peggiore, l'IMO, è uno snob grammaticale troppo zelante (sì, noi esistiamo; lo so perché possiamo sentire il nostro odore) scrive della documentazione che delinea un insieme di linee guida per la codifica che nessuno legge o segue. Diventano obsoleti nel tempo e quando nuove persone vengono aggiunte alla squadra e gli anziani se ne vanno, diventano semplicemente stantii.

Quindi, sorgono alcuni conflitti e qualcuno si trova nella scomoda posizione di dover confrontare qualcun altro sullo stile di codifica - questo tipo di confronto dovrebbe essere fatto da strumenti e non da persone. In breve, questo metodo di applicazione è il meno desiderabile, secondo me, perché è fin troppo facile da ignorare e supplica semplicemente i programmatori di discutere di cose stupide.

Un'opzione migliore (di nuovo, IMO) è di lanciare avvisi in fase di compilazione (o qualcosa di simile), a condizione che l'ambiente di compilazione lo supporti. Non è difficile configurarlo in VS.NET, ma non sono a conoscenza di altri ambienti di sviluppo con caratteristiche simili.

Le linee guida di stile sono estremamente importanti, sia per la progettazione che per lo sviluppo, perché accelerano la comunicazione e le prestazioni delle persone che lavorano in modo collaborativo (o anche da sole, in sequenza, come quando raccolgono i pezzi di un vecchio progetto). Non avere un sistema di convenzioni all'interno di un'azienda significa semplicemente chiedere alle persone di essere il più improduttive possibile. La maggior parte dei progetti richiede collaborazione e anche quelli che non lo sono possono essere vulnerabili al nostro naturale desiderio di esercitare le nostre capacità di programmazione e tenerci aggiornati. Il nostro desiderio di apprendere ostacola la nostra coerenza, il che è una cosa positiva in sé e per sé, ma può far impazzire un nuovo dipendente cercando di imparare i sistemi su cui sta saltando.

Come ogni altro sistema pensato per il bene e non per il male, il vero potere della guida è nelle mani della sua gente. Gli stessi sviluppatori determineranno quali sono le parti essenziali e utili e quindi, si spera, le useranno.

Come la legge. O la lingua inglese.

Le guide di stile dovrebbero essere profonde quanto vogliono - se si presentano nella sessione di brainstorming, dovrebbero essere incluse. È strano come hai formulato la domanda perché alla fine della giornata non c'è modo di & Quot; imporre & Quot; una guida di stile perché è solo una GUIDA.

RTFM, quindi raccogli le cose buone e vai avanti.

Sì, penso che le aziende dovrebbero. Potrebbe essere necessario che lo sviluppatore si abitui allo stile di codifica, ma secondo me un buon programmatore dovrebbe essere in grado di lavorare con qualsiasi stile di codifica. Come ha detto Midhat: è importante avere una base di codice coerente.

Penso che questo sia importante anche per i progetti opensource, non esiste un supervisore che ti dica come scrivere il tuo codice ma molte lingue hanno specifiche su come dovrebbero essere i nomi e l'organizzazione del tuo codice. Questo aiuta molto quando si integrano componenti opensource nel progetto.

Certo, le linee guida sono buone e, a meno che non sia una notazione ungherese usata male (ah!), probabilmente migliorerà la coerenza e renderà più semplice la lettura del codice di altre persone. Le linee guida dovrebbero essere solo linee guida, non regole rigide applicate ai programmatori. Potresti dirmi dove mettere le parentesi graffe o non usare nomi come temp, ma ciò che non puoi fare è costringermi ad avere spazi attorno ai valori di indice tra parentesi quadre (hanno provato una volta ...)

Sì.

Gli standard di codifica sono un modo comune per garantire che il codice all'interno di una determinata organizzazione segua il Principio della minima sorpresa: coerenza negli standard che vanno dalla denominazione variabile al rientro all'utilizzo di parentesi graffe.

I programmatori che hanno i loro stili e i loro standard produrranno solo una base di codice che è incoerente, confusa e frustrante da leggere, specialmente su progetti più grandi.

Questi sono gli standard di codifica per un'azienda per cui lavoravo. Sono ben definiti e, sebbene mi ci sia voluto un po 'di tempo per abituarmi, significava che il codice era leggibile da tutti noi e uniforme fino in fondo.

Penso che gli standard di codifica siano importanti all'interno di un'azienda, se nessuno è impostato, ci saranno scontri tra gli sviluppatori e problemi di leggibilità.

Avere il codice uniforme fino in fondo presenta un codice migliore all'utente finale (quindi sembra che sia scritto da una persona - che, dal punto di vista degli Utenti finali, dovrebbe - quella persona " la società " e aiuta anche con la leggibilità all'interno del team ...

Uno stile di codifica comune promuove la coerenza e semplifica la comprensione, la gestione e l'espansione dell'intera base di codice da parte di persone diverse, non solo dei loro pezzi. Inoltre, rende più facile per le nuove persone apprendere il codice più velocemente. Pertanto, ogni team dovrebbe avere una guida su come dovrebbe essere scritto il codice.

Linee guida importanti includono (in nessun ordine particolare):

spazi bianchi e rientri
commenti standard: intestazioni di file, classi o metodi
convenzione di denominazione - classi, interfacce, variabili, spazi dei nomi, file
annotazioni di codice
organizzazione del progetto - strutture di cartelle, binari
librerie standard: quali modelli, generici, contenitori e così via da usare
gestione degli errori - eccezioni, hresults, codici di errore
threading e sincronizzazione

Inoltre, fai attenzione ai programmatori che non possono o non si adattano allo stile del team, indipendentemente da quanto possano essere brillanti. Se non giocano secondo una delle regole della squadra, probabilmente non giocheranno anche con le regole delle altre squadre.

Concordo sul fatto che la coerenza sia la chiave. Non puoi fare affidamento su IDE pretty-printing per salvare la giornata, perché ad alcuni dei tuoi sviluppatori potrebbe non piacere usare un IDE, e perché quando stai navigando attraverso una base di codice di migliaia di file di origine, semplicemente non è fattibile stampa tutti i file quando inizi a lavorarci, ed esegui un rollback in seguito in modo che il tuo VCS non tenti di ripristinare tutte le modifiche (intasando il repository con aggiornamenti inutili che gravano su tutti).

Suggerirei di standardizzare almeno quanto segue (in ordine decrescente di importanza):

Spazio bianco (è più semplice se scegli uno stile conforme alla stampa automatica di alcuni strumenti condivisi)
Denominazione (file e cartelle, classi, funzioni, variabili, ...)
Commenti (utilizzando un formato che consente la generazione automatica della documentazione)

La mia opinione:

Alcune regole di base sono buone in quanto aiutano tutti a leggere e mantenere il codice
Troppe regole sono cattive in quanto impedisce agli sviluppatori di innovare con modi più chiari di strutturare il codice
Lo stile individuale può essere utile per determinare la cronologia di un file di codice. È possibile utilizzare gli strumenti diff / blame ma il suggerimento è ancora utile

Gli IDE moderni ti consentono di definire un modello di formattazione. Se esiste uno standard aziendale, sviluppa un file di configurazione che definisca tutti i valori di formattazione che ti interessano e assicurati che tutti eseguano il formatter prima di controllare il loro codice. Se vuoi essere ancora più rigoroso al riguardo, puoi aggiungere un hook di commit al tuo sistema di controllo della versione per indentare il codice prima che venga accettato.

Sì in termini di utilizzo di uno standard di denominazione comune nonché di un layout comune di classi e codice dietro i file. Tutto il resto è aperto.

Ogni azienda dovrebbe. Lo stile di codifica coerente garantisce una maggiore leggibilità e manutenibilità della base di codice nell'intero team.

Il negozio in cui lavoro non ha uno standard di codifica unificato, e posso dire che (come gruppo) ne soffriamo enormemente. Quando non c'è volontà degli individui (come nel caso di alcuni dei miei colleghi), il caposquadra deve battere il pugno sul tavolo e imporre una qualche forma di linee guida standardizzate per la codifica.

Ogni lingua ha standard generali che vengono utilizzati dalla comunità. Dovresti seguirli nel miglior modo possibile in modo che il tuo codice possa essere gestito da altre persone abituate alla lingua, ma non è necessario essere dittatoriali al riguardo.

La creazione di uno standard ufficiale è sbagliata perché uno standard di codifica aziendale è generalmente troppo rigido e incapace di fluire con la comunità generale usando il linguaggio.

Se stai riscontrando un problema con un membro del team, esci davvero in uno stile di programmazione, è una cosa eccellente che il gruppo suggerisce delicatamente non è una buona idea durante una revisione del codice.

Standard di codifica: SÌ. Per motivi già trattati in questa discussione.

Standard di stile: NO. Il tuo leggibile, è la mia spazzatura sconcertante, e viceversa. I buoni commenti e il factoring in codice hanno un vantaggio molto maggiore. Anche rientro gnu.

Mi piace la risposta di Ilya perché incorpora l'importanza della leggibilità e l'uso dell'integrazione continua come meccanismo di applicazione. Hibri ha citato FxCop e penso che il suo uso nel processo di compilazione come uno dei criteri per determinare se una compilazione passa o fallisce sarebbe più flessibile ed efficace della semplice documentazione di uno standard.

Sono pienamente d'accordo sul fatto che gli standard di codifica dovrebbero essere applicati e che dovrebbe essere quasi sempre a livello di squadra. Tuttavia ci sono un paio di eccezioni.

Se il team sta scrivendo il codice che deve essere utilizzato da altri team (e qui intendo che altri team dovranno guardare la fonte, non solo usarla come libreria), allora ci sono vantaggi nel rendere standard comuni attraverso tutte le squadre lo usano. Allo stesso modo, se la politica della compagnia è quella di spostare frequentemente i programmatori da una squadra all'altra, o è in una posizione in cui una squadra spesso vuole riutilizzare il codice da un'altra squadra, allora è probabilmente meglio imporre standard in tutta l'azienda.

Esistono due tipi di convenzioni.

Convenzioni di tipo A: " per favore fai queste, è meglio "

e Tipo B: " si prega di guidare sul lato destro della strada " ;, mentre va bene guidare sull'altro lato, purché tutti facciano lo stesso modo.

Non esiste una squadra separata. Tutto il codice di una buona azienda è in qualche modo collegato e lo stile dovrebbe essere coerente. È più facile abituarsi a un nuovo stile che a venti stili diversi .

Inoltre, un nuovo sviluppatore dovrebbe essere in grado di rispettare le pratiche della base di codice esistente e di seguirle.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow