Quanto è importante un buon stile di codifica per la decisione di assumere un programmatore? [chiuso]

Come sai che (i) avrà problemi ad adattarsi? Solo perché usano uno stile di codifica diverso? È piuttosto presuntuoso. Sono stato un appaltatore per molto tempo, e non importa quale stile di codifica sia usato, tu ti adatti. Potrebbe richiedere del tempo, ma le abitudini si formano abbastanza rapidamente.

Spero che codificando lo stile non si intenda solo l'indentazione e il layout del codice. Si tratta facilmente di utilizzare un formattatore di codice e di integrarlo nel tuo sistema di controllo della versione.

Prendendo lo stile di codifica per significare cose come la denominazione, l'ordinamento generale, la separazione delle unità e tutto ciò che riguarda la leggibilità e la manutenibilità, la cosa più importante sullo stile di codifica è che ne hai uno. Non quale. Non avere uno stile di codifica è una bandiera rossa definita.

La seconda cosa più importante di qualsiasi stile di codifica che qualcuno usa è che la usano in modo coerente. Quando qualcuno sembra usare uno stile di codifica, ma spesso "peccati" contro di esso, questa è un'altra bandiera rossa definita.

Avendo programmato centinaia di progetti diversi per quasi un centinaio di clienti diversi, vorrei sottolineare un punto.

Lo stile di codifica (e il cavillare sullo stile di codifica) è una completa perdita di tempo.

Passaci sopra.

Ho letto molto codice da molti programmatori diversi. (Assumi una squadra media di 5 e 100 squadre diverse: sono 500 collaboratori.) Lo stile non ha importanza.

Ho visto codice carino ma patologicamente sbagliato.

[C'è un limite. L'offuscamento intenzionale è motivo di risoluzione. In breve, lo stile è una perdita di tempo.]

Lo stile di codifica è la "frontiera finale"

Se hai risolto tutti i problemi dello sviluppo del software; se riesci a produrre codice senza errori più o meno istantaneamente; se il tuo livello di qualità è così elevato non hai più una coda di bug-fix; se la tua usabilità è così favolosa non hai più un help desk; se riesci a ottimizzare spietatamente fino al punto in cui non hai una server farm, ma esegui l'impresa da un iPad ...

Quando non c'è più nulla da risolvere, puoi finalmente concentrarti sullo stile di codifica.

Fino ad allora, ci sono numerosi problemi che sono più grandi e più preziosi dello stile.

Giudicare i programmatori in base allo stile di codifica è il 50% di snobismo e il 50% di insicurezza.

Mi piace che il mio codice appaia pulito e ordinato, e sembra che anche il tizio che l'OP ha raggirato nel link lo faccia. Il nostro codice non ha lo stesso aspetto, ma entrambi usiamo uno stile che ci aiuta a capire il codice quando torniamo ad esso. Non ho assolutamente avuto problemi a capire il suo codice e dubito che l'OP abbia funzionato. Lo stile di codifica "consiglio" non è altro che uno scatto facile e poco costoso in cui puoi esprimere la tua immensa saggezza sul perché le parentesi graffe dovrebbero essere sulla riga successiva. Non importa affatto. Ciò che rende il codice difficile da leggere è:

• convenzioni di denominazione assurde (o la loro mancanza) che non descrivono ciò che rappresentano.
• folle flusso di programmi che rende difficile dire cosa sta accadendo (goto, try / catch con la logica di business, ecc.).
• follemente lunghe funzioni che fanno più cose di quante il cervello possa tenere traccia di.

Ho difficoltà a immaginare un codice che non abbia fatto nulla di quanto elencato sopra, ma era ancora difficile da leggere, specialmente con uno strumento come Style Cop.

È ridicolo avere il formato del codice come fattore quando si decide di assumere qualcuno.

1. Ci sono molti altri fattori importanti da considerare.
2. La maggior parte degli sviluppatori può adattare il proprio stile.
3. Se il formato è così importante, utilizza un programma di formattazione del codice e un programma di controllo dei pelucchi.

Non assumere un buon sviluppatore perché non aggiunge uno spazio dopo che una virgola è sciocca.

Suppongo che tu abbia uno stile di formattazione ufficiale in azienda.

Quindi rendi estremamente semplice riformattare qualsiasi sorgente nello stile ufficiale e preferibilmente eseguirla automaticamente ogni volta che viene salvato il file sorgente.

Ogni programmatore degno di questo nome crescerà amandolo perché garantisce una qualità più elevata riducendo al minimo i diff per i commit.

Usa StyleCop

Se stai usando Visual Studio, puoi sempre forzare le regole di StyleCop con la tua compilation, che renderà il tuo codice almeno leggibile.

I reject unreadable code arguably non-standard styled, because it will become very hard to maintain in the future - even by the authors themselves. This has been proved many times in the past.

Formattazione codice integrata CVS = soluzione ottimale

Sarebbe davvero bello se qualcuno dei CVS supportasse la formattazione automatica del codice durante i check-in. Dovresti solo impostare le tue priorità di stile, il codice dovrebbe essere formattato prima di essere salvato. Ciò renderebbe obsoleto lo stile specifico per lo sviluppatore in termini di formattazione del codice. Posso vedere il problema se alcuni sviluppatori utilizzano caratteri di indentazione diversi. Non è così problematico per me guardare un codice diverso (e posso riformattarlo facilmente e velocemente) ma il DIFF diventa più difficile da gestire. Un sacco di falsi positivi nello strumento DIFF.

Molto al di sotto dei seguenti dettagli molto più importanti:

• Adattamento team
• Capacità di risoluzione dei problemi
• Comunicazione

Gli stili di codifica possono essere appresi dalla maggior parte delle persone che hanno gli ultimi due elencati sopra.

Tuttavia, di solito vedo un campione di codice prima dell'intervista finale, e se lo stile di codifica è molto lontano da quello che usiamo, mi concentrerò sulle domande che espongono la loro capacità di adattamento.

Se lo stile è coerente e quella persona è in grado di adattarsi (cambiare) a un altro stile, non vedo alcun problema.

Se lo stile corrente è diverso da quello che usi, ciò non significa che sia cattivo. Per il candidato, potrebbe avere senso completo.

Proprio come hanno detto gli altri, avere problemi nell'adattare potrebbe essere l'unico problema.

Non direi che questo non è un contratto preciso, ma è una strong argomentazione contro questa persona.

In realtà non mi preoccuperei dello stile di codifica, ma di questa incapacità di adattarmi essendo un sintomo di un problema generale. Avrei paura che il candidato trovasse difficile adattarsi anche ad altri aspetti della cultura della squadra.

Se non riesci a concentrarti su come usare lo stile pascal invece di quello stile cammello, allora potresti avere problemi a ricordare di iniziare una nuova serie di caffè se dovessi prendere l'ultima tazza. Quel genere di cose può essere davvero dannoso per la squadra.

(E sì, sono un tossicodipendente della caffeina.)

Secondo me, uno stile di codice buono è essenziale per un programmatore con cui lavorare.

Avere uno stile di codice buono è una questione di sviluppo personale. È un indicatore che ha già raggiunto questo programmatore.

La domanda è se la tua azienda vuole "professionisti alti" o "potenziali alti". Se hai bisogno di "professionisti di alto livello" e non c'è spazio per l'apprendimento e l'evoluzione, lo stile del codice è un criterio decisivo.

Se c'è spazio per l'evoluzione e lo sviluppo dei programmatori, è meglio che ti preoccupi della sua capacità di imparare velocemente o di pensare in modo creativo.