Devo seguire un cattivo stile di codifica solo per seguire le convenzioni stabilite sul mio posto di lavoro?

Lavoro nel mio lavoro da circa un anno. Lavoro principalmente nella nostra interfaccia GUI che utilizza metodi da un backend C, ma in genere non devo gestirli ad eccezione dei valori restituiti. La nostra GUI è strutturata in modo abbastanza ragionevole, dati i nostri limiti.

Mi è stato assegnato il compito di aggiungere una funzione alla parte della riga di comando del programma. Molte di queste funzioni sono lunghe 300 linee e difficili da usare. Sto cercando di raccoglierne pezzi per ottenere informazioni specifiche sull'allarme e ho problemi a tenermi organizzato. So che sto rendendo i miei test più complicati eseguendoli in un'unica lunga funzione.

Devo semplicemente tenere tutto in una funzione enorme secondo lo stile delle funzioni esistenti o devo incapsulare gli allarmi nelle loro stesse funzioni?

Non sono sicuro se sia appropriato andare contro le attuali convenzioni di codifica o se dovrei solo mordere il proiettile e rendere il codice un po 'più confuso per me stesso da scrivere.

In sintesi, sto confrontando

showAlarms(){
    // tons of code
}

contro

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDIT: Grazie per il consiglio a tutti, ho deciso che ho intenzione di progettare il mio codice factored, e quindi chiedere quello che vogliono, e se lo vogliono tutto in uno posso solo tagliare dal mio codice factored e trasformarlo in 1 grande funzione. Questo dovrebbe permettermi di scriverlo e testarlo più facilmente anche se lo vogliono tutto il codice in una singola definizione.

AGGIORNAMENTO: Hanno finito per essere felici con il codice fattorizzato e più di una persona mi ha ringraziato per aver impostato questo precedente.

Questo è davvero tra te e i tuoi compagni di squadra. Nessun altro può dirti la risposta giusta. Tuttavia, se posso osare leggere tra le righe, il fatto che tu chiami questo stile "cattivo" fornisce alcune informazioni che suggeriscono che è meglio prenderlo lentamente. Pochissimi stili di codifica sono in realtà "cattivi". Ci sono quelli che non userei io, ma hanno sempre una rima o una ragione per loro. Ciò suggerisce, per me, che c'è di più nella storia di quanto tu abbia visto finora. Chiedere in giro sarebbe una chiamata molto saggia. Qualcuno potrebbe sapere qualcosa che tu non sai.

Mi sono imbattuto in questo, personalmente, durante la mia prima incursione nella codifica mission-critical in tempo reale. Ho visto il codice in questo modo:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Essendo lo sviluppatore OO C ++ brillante e brillante che ero, li ho immediatamente chiamati fuori sui rischi di bug che avevano bloccando e sbloccando manualmente i mutex, piuttosto che usare RAII . Ho insistito sul fatto che era meglio:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Molto più semplice ed è più sicuro, giusto ?! Perché richiedere agli sviluppatori di ricordare di sbloccare i loro mutex su tutto il percorso del flusso di controllo quando il compilatore può farlo per te!

Bene, quello che ho scoperto in seguito è che c'era una ragione procedurale per questo. Abbiamo dovuto confermare che, sì, il software ha funzionato correttamente e che c'era un elenco finito di strumenti che ci era permesso usare. Il mio approccio potrebbe essere stato migliore in un ambiente diverso, ma nell'ambiente in cui stavo lavorando, il mio approccio avrebbe facilmente moltiplicato la quantità di lavoro coinvolta nella verifica dell'algoritmo dieci volte perché ho appena portato un concetto C ++ di RAII in una sezione di codice che era tenuto agli standard che erano davvero più suscettibili al pensiero in stile C.

Quindi quello che sembrava uno stile di codifica cattivo, decisamente pericoloso, per me era in realtà ben pensato e la mia "buona" soluzione era in realtà quella pericolosa che avrebbe causato problemi lungo la strada.

Quindi chiedi in giro. C'è sicuramente uno sviluppatore senior che può lavorare con te per capire perché lo fanno in questo modo. Oppure, c'è uno sviluppatore senior che può aiutarti a capire i costi e i benefici di un refattore in questa parte del codice. Ad ogni modo, chiedi in giro!

Sinceramente, credi che avere funzioni difficili da usare, con 300 linee, sia solo una questione di stile? Quindi seguire il cattivo esempio potrebbe mantenere uno stato migliore del programma generale a causa della coerenza? Immagino che tu non ci creda, altrimenti non avresti fatto questa domanda qui.

La mia ipotesi è che queste funzioni siano così lunghe perché nella nostra attività ci sono molti programmatori mediocri che si limitano a sovrapporre funzionalità a funzionalità, senza preoccuparsi di leggibilità, qualità del codice, denominazione corretta, unit test, refactoring e non hanno mai imparato a creare astrazioni adeguate . Devi decidere tu stesso se vuoi seguire quel branco o se vuoi essere un programmatore migliore.

Addendum, a causa dei commenti: "300 righe" e "difficile da usare" sono forti indicazioni IMHO per codice errato. Per la mia esperienza è molto improbabile che esista un "motivo tecnico nascosto" per cui tale codice non può essere implementato in modo più leggibile, paragonabile all'esempio della risposta di Cort Ammon. Tuttavia, sono d'accordo con Cort che dovresti discuterne con i responsabili nel team - non per trovare oscuri motivi per cui il codice o questo "tipo di stile" non può essere modificato, ma per scoprire come il codice può essere refactored in modo sicuro senza rompere le cose .

No.

Nel libro Pragmatic Programmer l'autore parla della teoria della finestra rotta .

Questa teoria afferma:

Prendi in considerazione un edificio con alcune finestre rotte. Se le finestre non vengono riparate, i vandali tendono a rompere qualche finestra in più. Alla fine, potrebbero persino irrompere nell'edificio e, se non è occupato, potrebbero diventare abusivi o fuochi leggeri all'interno.

O considera un marciapiede. Si accumulano alcuni rifiuti. Presto si accumulano più rifiuti. Alla fine, le persone iniziano persino a lasciare sacchi di rifiuti dai ristoranti da asporto lì o addirittura irrompono in auto.

Nel libro l'autore scrive un parallelo tra questa teoria e questo codice. Una volta trovato un codice come questo, ti fermi e ti poni la stessa domanda.

E la risposta è: No.

Una volta che lasci questa finestra rotta - nel nostro caso, codice errato - questo creerà l'effetto che tutti lasceranno indietro le finestre rotte.

E un giorno il codice si aprirà.

Dai una copia di Clean Code e Clean Coder a tutti.

E mentre sei nell'argomento, anche una copia di TDD è buona.

Sì, provaci. Struttura! = Stile

Stai parlando di struttura, non di stile. Le linee guida di stile non prescrivono (di solito) la struttura, poiché la struttura viene generalmente scelta per la sua adeguatezza per un problema specifico, non per un'adeguatezza a un'organizzazione.

Stai attento

Sii dannatamente sicuro di non causare conseguenze negative in altre aree che potrebbero non esserti verificate. Per esempio,

• Assicurati di non complicare le differenze o le fusioni di codice perché hai annullato qualsiasi somiglianza con il codice esistente.
• Assicurati che i flussi di eccezioni si riempiano correttamente e che le tracce dello stack non siano inquinate con un enorme mucchio di assurdità illeggibili.
• Assicurati di non esporre accidentalmente punti di ingresso pubblici che potrebbero causare problemi se chiamati direttamente (non inserirli nella mappa e / o non esportarli).
• Non ingombrare lo spazio dei nomi globale, ad esempio se le funzioni più piccole richiedono tutte una sorta di contesto globale precedentemente dichiarato nell'ambito della funzione locale.
• Assicurati di guardare qualsiasi registro e chiediti se eri nel team di supporto se i registri generati dal tuo codice sarebbero confusi se visti intrecciati con i registri di qualsiasi codice che non tocchi.
• Assicurati di non aderire a stile esistente, ad esempio, anche se non stanno usando vecchia scuola la notazione ungherese e fa sanguinare gli occhi, rimanere in linea con il codice di base generale. L'unica cosa più dolorosa della lettura della notazione ungherese è la lettura del codice che utilizza una dozzina di diversi tipi di notazione a seconda di chi ha scritto cosa.

Sii gentile

Ricorda che fai parte di una squadra e, sebbene il buon codice sia importante, è anche molto importante che i membri della tua squadra siano in grado di mantenere le cose che hai scritto quando vai in vacanza. Cerca di attenersi a un flusso che avrà senso per le persone che sono abituate al vecchio stile. Solo perché sei il ragazzo più intelligente nella stanza non significa che dovresti parlare sopra la testa di tutti!

Non lo vedo come una convenzione di codice. Vedo questo come qualcuno che non capisce come scrivere codice gestibile che sia facile da capire. Vorrei suddividere il codice in diverse funzioni mentre suggerisci ed educi il tuo team sui vantaggi di farlo mentre provo a capire perché ritengono che le funzioni a 300 righe siano accettabili. Sarei molto interessato a sentire il loro ragionamento.

La risposta è nella revisione del codice.

La vera domanda è se trasformi un codice ben ponderato, sarai l'unico disposto a lavorarci?

Come la maggior parte delle persone qui, credo che le funzioni di 300 linee siano un abominio. Tuttavia, portare Windex in una discarica non farà molto bene. Il problema non è il codice, sono i programmatori.

Solo avere ragione non è abbastanza. Devi vendere persone con questo stile. Almeno leggendolo. Se non lo fai finisci come questo povero ragazzo: licenziato perché le tue abilità sono troppo al di sopra dei tuoi colleghi

Inizia in piccolo. Chiedi in giro e scopri se qualcun altro favorisce le funzioni più piccole. Meglio ancora curiosare nella base di codice e vedere se riesci a capire chi scrive i più piccoli (potresti scoprire che il codice più brutto è il codice più vecchio e gli attuali programmatori stanno scrivendo un codice migliore). Parla con loro di questo e vedi se hai un alleato. Chiedi se conoscono qualcun altro che si sente allo stesso modo. Chiedi se conoscono qualcuno che odia le piccole funzioni.

Riunisci questo piccolo gruppo e parla delle modifiche. Mostra loro il tipo di codice che desideri scrivere. Assicurati che possano leggerlo. Prendi sul serio tutte le obiezioni. Apporta le modifiche. Ottieni il tuo codice approvato. Ora hai il potere di un incontro alle tue spalle. Alcuni di questi e puoi produrre un documento di una pagina che accetta esplicitamente il nuovo stile che hai introdotto.

Le riunioni sono cose sorprendentemente potenti. Possono produrre influenza. Clout è ciò che userete per combattere coloro che si oppongono a questo movimento. Ed è quello che è a questo punto. Un movimento. Stai lottando per il diritto di migliorare lo status quo. Le persone temono il cambiamento. Avrai bisogno di dolci chiacchiere, cajole e prod. Ma con un po 'di fortuna trasformerai l'essere giusto in essere accettato.

A volte devi seguire il flusso.

Come hai detto, ti è stato assegnato il compito di implementare una funzione in una base di codice di lavoro esistente.

Indipendentemente dal disordine, e capisco che è allettante tentare di ripulirlo. ma nel mondo degli affari non hai sempre la possibilità di refactificare il codice.

Direi semplicemente fai quello che ti è stato chiesto di fare e andare avanti.

Se ritieni che valga la pena eseguire il refactoring o la riscrittura di quanto sia necessario per metterlo in discussione con il team.

Prima di affermare che le pratiche sono cattive, vorrei prima fare un passo verso la comprensione della ragione di grandi metodi e altre pratiche che potrebbero rivelarsi cattive.

Quindi, dovresti assicurarti che la copertura del test sia abbastanza alta o molto alta (per quanto puoi prendere senza un grande refactoring). In caso contrario, lavorerei per rendere la copertura molto elevata anche se non hai scritto il codice. Questo aiuta a costruire un rapporto e il tuo nuovo team ti prenderà più sul serio.

Una volta che hai coperto queste basi, nessuno nella loro mente giusta ti sfiderebbe. Come elemento bonus, esegui alcuni micro-benchmark e questo si aggiungerà davvero al tuo caso.

Spesso, il modo in cui lo pronunci è molto importante per cambiare la cultura del codice. Dare l'esempio. O ancora meglio, aspetta un pezzo di codice che puoi scrivere - refactor e unit test all'inferno e viola - sarai ascoltato.

Questo tipo di domanda è fondamentalmente "per favore, leggi attentamente i miei compagni di squadra ". Le persone casuali su Internet non possono farlo, quindi tutte le risposte che otterrai sono solo opinioni personali delle persone sullo stile di programmazione. Il consenso è che sono preferibili metodi più brevi, ma sembra che tu lo pensi già così, quindi non è necessario ribadirlo.

Pertanto, l'attuale base di codice sembra utilizzare uno stile di codifica diverso da quello che preferisci. Cosa dovresti fare Per prima cosa devi capire:

1. È una decisione di progettazione deliberata supportata dal tuo attuale team?
2. Vogliono che tu segua questo stile?

C'è solo un modo per scoprirlo. Chiedi .

Potrebbero esserci più ragioni per avere lunghe funzioni. Potrebbe essere perché il team ritiene che le funzioni lunghe siano migliori di più funzioni brevi. Potrebbe anche essere perché è un codice legacy e il team preferisce che il nuovo codice segua un design più pulito. Quindi entrambe le scelte potrebbero metterti nei guai come sviluppatore, se non parli con il team e capisci il loro ragionamento.

Esistono diversi livelli di "stile".

Ad un livello, generalmente parte delle convenzioni di codifica, ciò significa dove inserire spazi bianchi, linee vuote, parentesi e come nominare le cose (maiuscole, sottolineature, ecc.).

Ad un altro livello c'è il modello di programmazione, a volte cose come evitare la statica, o usare interfacce su classi astratte, come esporre dipendenze, forse persino evitare alcune caratteristiche del linguaggio esoterico.

Poi ci sono le librerie e i framework in uso dal progetto.

A volte ci sarà un limite massimo alla dimensione della funzione. Ma raramente esiste un limite minimo! Quindi, dovresti scoprire quali di queste cose i poteri che sono importanti e cercare di rispettarlo.

Devi scoprire se il team è contrario al refactoring del codice esistente, che dovrebbe essere fatto indipendentemente dall'aggiunta di un nuovo codice quando possibile.

Tuttavia, anche se non vogliono riformattare il codice esistente, potresti essere in grado di introdurre alcuni livelli in astrazioni per il tuo nuovo codice che aggiungi, il che significa che nel tempo puoi sviluppare una base di codice migliore e forse migrare il vecchio codice come manutenzione ne richiede.