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

Anche da studente mi viene chiesto di rivedere il codice dei programmatori che hanno (non) superato un test (creare un elenco di numeri di Fibonacci su Android).

Mentre sono molto severo sullo stile di codifica, ho appena letto dello stile "a blocchi" che qualcuno ha usato (leggi i commenti!) .

Nella mia posizione, consiglierei di non assumere un ragazzo usando questo tipo di stile. Il codice è completamente l'opposto dello stile di codifica utilizzato nella mia azienda.

Durante la ricerca dello stile di programmazione e di come affrontarlo, sono curioso di sapere una cosa: dovrei assumere un ragazzo che avràguai seri adattare lo stile di codifica utilizzato nell'azienda?

Per favore: questa non dovrebbe essere una discussione sullo stile di codifica in generale e quale è meglio. Riguarda l'importanza dello stile di codifica per la decisione di assumere qualcuno!

Maggiori informazioni:

Non sono il tipo che prende la decisione, do solo la mia opinione in base al codice. Il ragazzo deve passare un'intervista in cui il nostro capo di qualunque cosa controlli le soft skills. Se ha superato questo, deve superare il nostro piccolo test di abilità ed è qui che a volte mi viene chiesto di rivedere il codice scritto. Non sono in grado di dire sì o no. Voglio solo sapere quanto importante stile di codifica dovrebbe essere per la mia recensione ...

Come fai a sapere che avrà difficoltà ad adattarsi? Solo perché usano uno stile di codifica diverso? È piuttosto presuntuoso. Sono un appaltatore da molto tempo e, indipendentemente dallo stile di codifica utilizzato, ti adatti. Potrebbe volerci del tempo, ma le abitudini si formano abbastanza rapidamente.

Spero che per stile di codifica non significhi solo rientro e layout del codice. Ciò è facilmente gestibile utilizzando un formattatore di codice e integrandolo nel 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 dello stile di codifica è che ne hai uno. Non quale. Non avere uno stile di codifica è una bandiera rossa definita.

La seconda cosa più importante su qualunque stile di codifica venga utilizzato da qualcuno è che lo utilizzino 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 cento clienti diversi, vorrei sottolineare un punto.

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

Farsene una ragione.

Ho letto molto codice da molti programmatori diversi. (Supponi una dimensione mediana di 5 e 100 squadre diverse. Sono 500 collaboratori.) Lo stile non ha importanza.

Ho visto un codice carino ma patologicamente sbagliato.

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

Lo stile di programmazione è la "frontiera finale"

Se hai risolto tutti i problemi di sviluppo del software; se riesci a produrre codice privo di errori più o meno all'istante; se il tuo livello di qualità è così alto da non avere più una coda di correzione dei bug; se la tua usabilità è così favolosa da non avere 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ù niente da risolvere, puoi finalmente concentrarti sullo stile di codifica.

Fino ad allora, ci sono numerosi problemi 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 anche il ragazzo su cui l'OP si è storto nel link. Il nostro codice non ha lo stesso aspetto, ma entrambi utilizziamo 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 fatto lo stesso. Lo "consiglio" in stile codice non è altro che un semplice colpo economico in cui puoi trasmettere 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 folle (o mancanza di esse) che non descrivono ciò che rappresentano.
• flusso di programma folle che rende difficile dire cosa sta succedendo (vai a, prova a catturare con la logica aziendale, ecc.).
• funzioni follemente lunghe che fanno più cose di quante ne possa tenere il cervello.

Ho difficoltà a immaginare qualsiasi codice che non ha fatto nulla delle cose sopra elencate, ma era ancora difficile da leggere, specialmente con uno strumento come Style Cop.

È ridicolo che il formato del codice sia un fattore decisivo 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, usa un riformattatore di codice e un correttore di lanugine.

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 facile riformattare qualsiasi sorgente allo stile ufficiale e preferibilmente farlo accadere automaticamente ogni volta che il file sorgente viene salvato.

Ogni programmatore degno del suo sale lo apprezzerà perché garantisce una qualità superiore riducendo al minimo le differenze per i commit.

Usa StyleCop

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

Respingo il codice illeggibile probabilmente con uno stile non standard , perché diventerà molto difficile da mantenere in futuro, anche dagli autori stessi. Questo è stato dimostrato molte volte in passato.

Formattazione del codice integrata CVS = soluzione ottimale

Sarebbe davvero fantastico se qualcuno dei CVS supportasse la formattazione automatica del codice ai check-in. Devi solo impostare le priorità di stile, il codice verrebbe formattato prima di essere salvato. Ciò renderebbe obsoleto lo stile specifico dello sviluppatore in termini di formattazione del codice. Riesco a vedere il problema se alcuni sviluppatori utilizzano caratteri di rientro diversi. Non è così problematico per me guardare un codice diverso (e posso riformattarlo facilmente e velocemente) ma DIFF diventa più difficile da gestire. Molti falsi positivi nello strumento DIFF.

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

• Team Fit
• 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, generalmente vedo un esempio di codice prima dell'intervista finale e se lo stile di codifica è molto lontano da quello che usiamo, mi concentrerò su domande che espongono la loro capacità di adattamento.

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

Se lo stile attuale è diverso da quello che usi non significa che sia male. Per il candidato, potrebbe avere perfettamente senso.

Proprio come altri hanno detto, avere problemi di adattamento potrebbe essere l'unico problema.

Non direi che si tratta di un assenso definitivo, ma è un argomento forte contro questa persona.

In realtà non mi preoccuperei dello stile di codifica, ma di questa incapacità di adattamento come sintomo di un problema generale. Avrei paura che il candidato potesse avere difficoltà ad adattarsi anche ad altri aspetti della cultura del team.

Se non riesci a distogliere lo sguardo usando lo stile pascal invece del budello in stile cammello, potresti avere difficoltà a ricordare di iniziare un nuovo lotto di caffè se dovessi prendere l'ultima tazza. Questo genere di cose può essere davvero dannoso per la squadra.

(E sì, sono un drogato di caffeina.)

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

Avere un buon stile di codice è una questione di sviluppo personale. È un indicatore del livello già raggiunto da questo programmatore.

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

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