Quali "best practice" popolari non sono sempre le migliori, e perché? [chiuso]

Le "migliori pratiche" sono ovunque nel nostro settore. Una ricerca di Google sulle "migliori pratiche di codifica" genera quasi 1,5 milioni di risultati. L'idea sembra portare conforto a molti; basta seguire le istruzioni e tutto andrà bene.

Quando leggo di una best practice - per esempio, ne ho appena letti diversi in Clean Code di recente - mi innervosisco. Questo significa che dovrei sempre usare questa pratica? Ci sono condizioni associate? Ci sono situazioni in cui potrebbe non essere una buona pratica? Come posso sapere con certezza fino a quando non avrò imparato di più sul problema?

Molte delle pratiche menzionate in Clean Code non mi andavano bene, ma onestamente non sono sicuro se ciò sia dovuto al fatto che sono potenzialmente cattive o se è solo il mio pregiudizio personale a parlare. So che molte persone di spicco nel settore tecnologico sembrano pensare che non ci siano buone pratiche , quindi almeno i miei fastidiosi dubbi mi mettono in buona compagnia.

Il numero di best practice di cui ho letto è semplicemente troppo numeroso per elencarlo qui o porre domande individuali, quindi vorrei formulare questa frase come una domanda generale:

Quali pratiche di codifica che sono comunemente etichettate come "migliori pratiche" possono essere non ottimali o addirittura dannose in determinate circostanze? Quali sono queste circostanze e perché rendono la pratica povera?

Preferirei conoscere esempi ed esperienze specifici.

Penso che tu abbia colpito l'unghia sulla testa con questa affermazione

Odierei prendere le cose al valore nominale e non pensarci criticamente

Ignoro quasi tutte le migliori pratiche quando non viene fornita una spiegazione sul perché esiste

Raymond Chen lo mette meglio in questo articolo quando dice

Un buon consiglio viene fornito con una logica in modo da poter dire quando diventa un cattivo consiglio. Se non capisci perché qualcosa dovrebbe essere fatto, allora sei caduto nella trappola della programmazione di culto del carico e continuerai a farlo anche quando non è più necessario o addirittura diventa deleteria.

Potrebbe anche buttarlo sul ring:

Premature optimization is the root of all evil.

No non lo è.

Il preventivo completo:

"Dovremmo dimenticare le piccole efficienze, diciamo circa il 97% delle volte: l'ottimizzazione prematura è la radice di tutti i mali. Eppure non dovremmo rinunciare alle nostre opportunità in quel 3% critico".

Ciò significa che sfrutti miglioramenti specifici e strategici delle prestazioni durante tutto il processo di progettazione. Significa che si utilizzano strutture di dati e algoritmi coerenti con gli obiettivi di prestazione. Significa che sei a conoscenza di considerazioni di progettazione che influiscono sulle prestazioni. Ma significa anche che non si ottimizza frivolosamente quando lo si fa, si otterranno piccoli guadagni a spese della manutenibilità.

Le applicazioni devono essere ben progettate, in modo che non cadano alla fine quando si applica un piccolo carico su di esse e quindi si finisce per riscriverle. Il pericolo con la citazione abbreviata è che, troppo spesso, gli sviluppatori lo usano come una scusa per non pensare alle prestazioni fino alla fine, quando potrebbe essere troppo tardi per fare qualcosa al riguardo. È meglio ottenere buone prestazioni fin dall'inizio, a condizione che non ci si concentri sulle minuzie.

Supponiamo che tu stia creando un'applicazione in tempo reale su un sistema incorporato. Scegli Python come linguaggio di programmazione, perché "L'ottimizzazione prematura è la radice di tutti i mali". Ora non ho nulla contro Python, ma è un linguaggio interpretato. Se la potenza di elaborazione è limitata e una certa quantità di lavoro deve essere eseguita in tempo reale o quasi in tempo reale e si sceglie una lingua che richiede più potenza di elaborazione per il lavoro di quella che si possiede, si viene fregati in modo regale, perché si ora devo ricominciare con un linguaggio capace.

Un ritorno per funzione / metodo.

Non reinventare la ruota è un dogma ampiamente mal utilizzato. La sua idea è che se esiste una soluzione adatta, usala invece di crearne una tua; oltre allo sforzo di risparmio, la soluzione esistente è probabilmente meglio implementata (senza errori, efficiente, testata) rispetto a quella che verrebbe inizialmente. Fin qui tutto bene.

Il problema è che raramente esiste una soluzione adatta al 100%. Potrebbe esistere una soluzione adatta all'80% e il suo utilizzo probabilmente va bene. Ma come circa il 60% adatto? 40%? Dove disegni la linea? Se non disegni la linea, potresti finire con l'incorporare una libreria gonfiata al tuo progetto perché stai usando il 10% delle sue funzionalità - solo perché vuoi evitare di "reinventare la ruota".

Se reinventi la ruota, otterrai esattamente ciò che desideri. Imparerai anche come realizzare le ruote. L'apprendimento facendo non dovrebbe essere sottovalutato. E alla fine, una ruota personalizzata potrebbe essere migliore della ruota generica standard.

"Unit Test Everything."

Ho sentito dire spesso che tutto il codice dovrebbe avere unit test, un punto su cui non sono d'accordo. Quando si dispone di un test per un metodo, qualsiasi modifica all'output o alla struttura di quel metodo deve essere effettuata due volte (una volta nel codice, una volta nel test).

Pertanto, i test unitari dovrebbero essere, a mio avviso, proporzionali alla stabilità strutturale del codice. Se sto scrivendo un sistema a strati dal basso verso l'alto, il mio livello di accesso ai dati avrà test del wazoo; il mio livello di logica aziendale sarà testato abbastanza bene, il mio livello di presentazione avrà alcuni test e le mie opinioni non avranno quasi nessun test.

Programmare sempre su interfacce.

A volte ci sarà una sola implementazione. Se ritardiamo il processo di estrazione di un'interfaccia fino al momento in cui ne vediamo la necessità, spesso scopriremo che non è necessario.

Non usare nulla di open source (o non Microsoft per te sviluppatori .NET)

Se Microsoft non lo ha sviluppato, non lo usiamo qui. Vuoi usare ORM - EF, vuoi usare IOC - Unity, vuoi loggarti - blocco applicativo di registrazione aziendale. Esistono così tante biblioteche migliori, eppure sono sempre bloccato a ordinare dal menu in dollari del mondo di sviluppo. Lo giuro ogni volta che sento le migliori pratiche di Microsoft, penso alle "Linee guida nutrizionali di McDonald". Certo, probabilmente li vivrai se li segui, ma sarai anche malnutrito e sovrappeso.

• Nota che questa potrebbe non essere la tua migliore pratica, ma è una pratica comune seguita quasi ovunque ho lavorato.

Orientamento agli oggetti

C'è il presupposto, solo perché il codice è "orientato agli oggetti", è magicamente buono. Quindi le persone continuano a spremere la funzionalità in classi e metodi, solo per essere orientati agli oggetti.

Tutto il codice dovrebbe essere commentato.

No, non dovrebbe essere. Qualche volta hai un codice evidente, ad esempio i setter non dovrebbero essere commentati, fino a quando non fanno qualcosa di speciale. Inoltre, perché dovrei commentare questo:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

Metodologie, in particolare mischia. Non riesco a mantenere una faccia seria quando sento gli adulti usare la frase "Scrum Master". Sono così stanco di sentire la protesta degli sviluppatori che alcuni aspetti della Metodologia X non funzionano per la loro azienda, solo per essere raccontati dal Guru So-and-So che la ragione per cui non funziona è che in realtà non sono dei veri professionisti di Metodologia X. "Scrum più forte, è necessario, mio ​​studente Padawan!"

Ci sono pepite di saggezza nelle metodologie agili --- molte di esse --- ma spesso sono immerse in così tanto letame che non posso combattere il mio riflesso del vomito. Prendi questo bit dalla pagina di mischia di Wikipedia :

Numerosi ruoli sono definiti in Scrum. Tutti i ruoli rientrano in due gruppi distinti - maiali e polli - in base alla natura del loro coinvolgimento nel processo di sviluppo.

Veramente? Maiali e galline, dici? Affascinante! Non vedo l'ora di presentare questo al mio capo ...

Mappatura relazionale degli oggetti ... http://en.wikipedia.org/wiki/Object-relational_mapping

Non voglio mai essere sottratto ai miei dati, né voglio perdere quel preciso controllo e ottimizzazione. La mia esperienza con questi sistemi è stata estremamente scarsa ... Le query generate da questi livelli di astrazione sono persino peggiori di quelle che ho visto off-shoring.

Scrivere i nomi delle funzioni come se fossero frasi inglesi:

Draw_Foo()
Write_Foo()
Create_Foo()

ecc. Potrebbe sembrare fantastico, ma è un problema quando stai imparando un'API. Quanto è più facile cercare un indice per "Tutto ciò che inizia con Foo"?

Foo_Draw()
Foo_Write()
Foo_Create()

eccetera.

MVC: trovo spesso che nascondere molti problemi di web design nell'approccio MVC si basa più sul rendere felice un framework (rotaie ecc.) Che sulla semplicità o sulla struttura. MVC è una delle preferite degli "astronauti dell'architettura" che sembrano apprezzare le impalcature eccessive rispetto alla semplicità. YMMV.

OO di classe - a mio avviso incoraggia strutture complesse di stato mutevole. gli unici casi convincenti che ho trovato per OO basato sulla classe nel corso degli anni sono gli esempi banali "forma-> rettangolo-> quadrato" che formano il capitolo 1 di qualsiasi libro OO

YAGNI

( Non ne avrai bisogno )

Questo approccio mi è costato ore e ore quando ho dovuto implementare funzionalità su una base di codice esistente, dove un'attenta pianificazione avrebbe incluso queste funzionalità in anticipo.

Le mie idee sono state spesso respinte a causa di YAGNI, e la maggior parte delle volte qualcuno ha dovuto pagare per quella decisione in seguito.

(Naturalmente si potrebbe sostenere che una base di codice ben progettata consentirebbe anche l'aggiunta di funzionalità in un secondo momento, ma la realtà è diversa)

Per SQL

1. Non usare i trigger
2. Nascondi sempre le tabelle dietro le viste

In ordine:

1. Sono una caratteristica che ha il suo posto. Hai più percorsi di aggiornamento per una tabella o richiedi il controllo al 100%?

2. Solo perché? Vorrei che se stessi eseguendo il refactoring per mantenere un contratto, ma non quando ho letto che le persone cambiano il punto di vista per adattarsi a qualsiasi modifica del tavolo

Modificare:

Numero 3: Evitare * con EXISTS. Prova 1/0. Funziona. L'elenco delle colonne non viene valutato secondo lo standard SQL. Pagina 191

Modelli di design per lo più. Sono sovrautilizzati e sottoutilizzati.

Il principio di responsabilità unica

^{("ogni classe dovrebbe avere una sola responsabilità; in altre parole, ogni classe dovrebbe avere una, e una sola, ragione per cambiare")}

Non sono d'accordo. Penso che un metodo dovrebbe avere solo una ragione per cambiare, e tutti i metodi in una classe dovrebbero avere una relazione logica tra loro , ma la classe stessa potrebbe effettivamente fare diverse cose (correlate).

Nella mia esperienza, questo principio troppo spesso viene applicato in modo troppo zelante e si finisce con molte piccole classi con un metodo. Entrambi i negozi agili in cui ho lavorato lo hanno fatto.

Immagina se i creatori dell'API .Net avessero avuto questo tipo di mentalità: piuttosto che List.Sort (), List.Reverse (), List.Find () ecc., Avremmo le classi ListSorter, ListReverser e ListSearcher!

Piuttosto che litigare più contro l'SRP (che in sé non è terribile in teoria) , condividerò alcune delle mie esperienze aneddotiche a lungo termine:

In un posto in cui ho lavorato, ho scritto un risolutore di flusso massimo molto semplice che consisteva in cinque classi: un nodo, un grafico, un creatore di grafici, un risolutore di grafici e una classe per utilizzare il creatore di grafici / solutori per risolvere un problema del mondo reale. Nessuno era particolarmente complesso o lungo (il solutore era di gran lunga il più lungo con circa 150 righe). Tuttavia, è stato deciso che le classi avevano troppe "responsabilità", quindi i miei colleghi hanno iniziato a riformattare il codice. Al termine, le mie 5 classi erano state estese a 25 classi, le cui linee di codice totali erano più del triplo di quelle che erano in origine. Il flusso del codice non era più ovvio, né lo scopo dei nuovi test unitari; Ora ho avuto difficoltà a capire cosa facesse il mio codice.

Allo stesso posto, quasi ogni classe aveva un solo metodo (la sua unica "responsabilità"). Seguire il flusso all'interno del programma era quasi impossibile e la maggior parte dei test unitari consisteva nel verificare che questa classe chiamasse codice da un'altra classe , entrambi i cui scopi erano ugualmente un mistero per me. C'erano letteralmente centinaia di classi in cui avrebbero dovuto esserci (IMO) solo dozzine. Ogni classe ha fatto solo una "cosa" , ma anche con convenzioni di denominazione come "AdminUserCreationAttemptorFactory" , era difficile dire la relazione tra le classi.

In un altro posto (che aveva anche la mentalità class-have-have-only-one-method ), stavamo cercando di ottimizzare un metodo che impiegava il 95% del tempo durante una certa operazione. Dopo averlo (piuttosto stupidamente) ottimizzato un po ', ho rivolto la mia attenzione al perché veniva chiamato un bajillion volte. Veniva chiamato in un ciclo in una classe ... il cui metodo veniva chiamato in un ciclo in un'altra classe ... che veniva anche chiamato in un ciclo ...

Tutto sommato, c'erano 13 livelli di loop distribuiti su 13 classi (sul serio). Ciò che una classe stava effettivamente facendo era impossibile da determinare semplicemente osservandolo: dovevi tracciare un grafico mentale di quali metodi chiamava, quali metodi chiamavano quei metodi e così via. Se fosse stato tutto sommato in un unico metodo, sarebbe stato lungo solo circa 70 righe con il nostro metodo problematico annidato all'interno di cinque livelli immediatamente evidenti di loop.

La mia richiesta di trasformare queste 13 classi in una classe è stata respinta.

Ora che hai menzionato Clean Code, sebbene contenga alcune buone idee, penso che la sua ossessione di trasformare tutti i metodi in sottometodi e quelli in sotto-metodi ecc. Sia stata portata troppo avanti. Invece di un paio di metodi a dieci righe, dovresti preferire venti linee (presumibilmente ben definite) a una linea. Ovviamente qualcuno pensa che sia pulito, ma a me sembra molto peggio della versione originale.

Inoltre, sostituendo semplici elementi elementari come

0 == memberArray.length

all'interno di una classe con una chiamata al metodo della classe come

isEmpty()

è un discutibile IMHO "miglioramento". Aggiunta: la differenza è che il primo controllo fa esattamente quello che dice: controlla se la lunghezza dell'array è 0. Ok, isEmpty()potrebbe anche controllare la lunghezza dell'array. Ma potrebbe anche essere implementato in questo modo:

return null != memberArray ? 0 == memberArray.length : true;

Cioè, include un controllo null implicito! Questo potrebbe essere un buon comportamento per un metodo pubblico - se l'array è nullo, allora qualcosa è certamente vuoto - ma quando parliamo di interni di classe, non va bene. Mentre l'incapsulamento verso l'esterno è un must, gli interni della classe devono sapere esattamente cosa sta succedendo all'interno della classe. Non è possibile incapsulare la classe da se stessa . Esplicito è meglio che implicito.

Ciò non significa che rompere i metodi lunghi o comportare confronti logici non vada bene; certo che lo è, ma fino a che punto farlo - dov'è il punto debole - è ovviamente una questione di gusti. Abbattere un metodo lungo si traduce in più metodi e ciò non viene fornito gratuitamente. Devi saltare il codice sorgente per vedere cosa sta realmente succedendo, quando puoi vederlo a colpo d'occhio se tutte quelle cose fossero in un unico metodo.

Direi addirittura che in alcuni casi un metodo a 1 riga è troppo breve per meritare di essere un metodo.

"Sii liberale con i commenti"

I commenti sono sicuramente una buona cosa, ma troppi sono altrettanto cattivi se non peggio che non sufficienti. Perché? Bene, le persone tendono a mettere a punto i commenti se ne vedono troppi inutili. Non sto dicendo che puoi avere un codice perfettamente autocompattante, ma è preferibile un codice che necessita di commenti per una spiegazione.

GoTo Considerato dannoso

Se stai implementando una macchina a stati, un'istruzione GOTO può avere più senso (leggibilità e codice efficiente) di un approccio di "programmazione strutturata". Alcuni colleghi hanno davvero preoccupato quando il primo pezzo di codice che ho scritto in un nuovo lavoro includeva non solo una ma diverse dichiarazioni di goto. Fortunatamente erano abbastanza intelligenti da rendersi conto che in realtà era la soluzione migliore in questo caso particolare.

Qualsiasi "best practice" che non consenta eccezioni sensate e documentate alle sue regole è semplicemente spaventosa.

I sacrifici che facciamo per rendere testabile il codice

Salto attraverso molti cerchi per rendere il mio codice testabile, ma non faccio finta che non lo farei se avessi la scelta. Tuttavia, sento spesso persone che spingono l'idea che si tratti di "buone pratiche". Queste pratiche includono (scritto nella lingua di .Net, ma si applica anche ad altre lingue) :

• Creazione di un'interfaccia per ogni classe. Questo raddoppia il numero di classi (file) da gestire e duplica il codice. Sì, la programmazione dell'interfaccia è buona, ma è a questo che servono gli specificatori pubblici / privati.
• Ogni classe non istanziata all'avvio richiede una factory. Chiaramente, new MyClass()è molto più semplice che scrivere una fabbrica, ma ora il metodo che lo crea non può essere testato da solo. Se non fosse per questo, farei solo 1/20 del numero di classi di fabbrica che faccio ora.
• Rendi pubblica ogni classe, il che vanifica lo scopo di avere specificatori di accesso sulle classi. Tuttavia, le classi non pubbliche non sono accessibili (e quindi testate) da altri progetti, quindi l'unica altra opzione è spostare tutto il codice di test nello stesso progetto (e quindi rilasciarlo con il prodotto finale).
• Iniezione di dipendenza. Devo chiaramente dare a ogni altra classe che uso un campo e un parametro di costruzione è significativamente più lavoro che semplicemente crearli quando ne ho bisogno; ma poi non posso più testare questa classe in isolamento.
• Il principio della responsabilità singola, che mi ha causato così tanti mal di testa, l'ho spostato nella sua risposta .

Quindi cosa potremmo fare per risolvere questo problema? Avremmo bisogno di un drastico cambiamento nell'architettura del linguaggio:

• Avremmo bisogno della capacità di deridere le lezioni
• Avremmo bisogno della capacità di testare metodi privati ​​di classi interne, da un altro progetto (questo può sembrare una vulnerabilità di sicurezza, ma non vedo alcun problema se il testato è costretto a nominare le sue classi tester) .
• L'iniezione di dipendenza (o la posizione del servizio), nonché qualcosa di equivalente al nostro modello di fabbrica esistente, dovrebbe essere una parte fondamentale del linguaggio.

In breve, abbiamo bisogno di un linguaggio progettato da zero con in mente la testabilità .

Separazione delle applicazioni in livelli; Livello dati, livello aziendale, livello dell'interfaccia utente

Il motivo principale per cui non mi piace questo è che la maggior parte dei luoghi che seguono questo metodo usano framework molto fragili per farlo. IE UI Layer è codificato a mano per gestire gli oggetti del livello aziendale, gli oggetti del livello aziendale sono codificati a mano per gestire le regole aziendali e il database, il database è SQL ed è già abbastanza fragile e gestito dal gruppo "DBA" a cui non piace il cambiamento.

Perché è così male? La richiesta di miglioramento più comune è probabilmente "Ho bisogno di un campo sullo schermo X che ha Y." Scoppio! Hai solo una nuova funzionalità che interessa ogni singolo livello e, se separi i livelli con programmatori diversi, è diventato un grosso problema che coinvolge più persone e gruppi, per un cambiamento molto semplice.

Inoltre, non so quante volte ho litigato con argomenti del genere. "Il campo del nome è limitato a una lunghezza massima di 30, si tratta di un livello dell'interfaccia utente, un livello aziendale o un problema del livello dati?" E ci sono cento argomenti e nessuna risposta giusta. La risposta è la stessa, influisce su tutti i livelli, non si vuole rendere stupida l'interfaccia utente e passare attraverso tutti i livelli, e fallire nel database, solo così l'utente scopre che la sua voce è troppo lunga. Se lo cambi, influisce su tutti i livelli, ecc.

Anche gli "strati" tendono a perdere; Se uno strato è fisicamente separato dai confini di processo / macchina (IE Web UI e logica di backend aziendale), le regole vengono duplicate per far funzionare tutto ragionevolmente bene. Vale a dire che alcune logiche aziendali finiscono nell'interfaccia utente, anche se si tratta di una "regola aziendale", poiché l'utente ha bisogno che l'interfaccia utente sia reattiva.

Se il framework utilizzato o l'architettura utilizzata è resistente a piccole modifiche e perdite, ovvero basato su metadati e regolato dinamicamente su tutti i livelli, può essere meno doloroso. Ma la maggior parte dei framework è una vera seccatura, che richiede modifiche dell'interfaccia utente, modifiche del livello aziendale e modifiche al database, per ogni piccola modifica, e che causa più lavoro e meno aiuto di quanto la tecnica dovrebbe produrre.

Probabilmente mi sbatterò per questo, ma eccolo :)

JavaBeans

L'uso di JavaBeans in Java. Vedi la mia domanda Perché non dovrei usare POJO immutabili invece di JavaBeans? su StackOverflow.

User Stories / Use Cases / Personas

Comprendo la necessità di questi quando programmate per un settore che non conoscete, ma penso che quando sono implementati in piena forza diventano troppo corporativi e diventano una perdita di tempo.

80 limiti char / line sono stupidi

Capisco che alcuni compromessi devono essere fatti per adattarsi al ritmo del corridore più lento sul lato della GUI (limitazioni della risoluzione dello schermo, ecc.) Ma perché questa regola si applica alla formattazione del codice?

Vedi ... C'era questa piccola invenzione chiamata barra di scorrimento orizzontale creata per gestire lo spazio dello schermo virtuale al di fuori del limite di pixel più a destra. Perché gli sviluppatori, che sono riusciti a creare grandi strumenti per migliorare la produttività come l'evidenziazione della sintassi e il completamento automatico, non lo usano?

Certo, ci sono editor CLI usati religiosamente dai dinosauri * nix che seguono le vecchie e stanche limitazioni dei loro terminali VT220 ma perché tutti noi siamo tenuti allo stesso standard?

Dico, avvita il limite di 80 caratteri. Se i dinosauri sono abbastanza epici da hackerare su emacs / vim tutto il giorno, perché non dovrebbe essere in grado di creare un'estensione che avvolge automaticamente le linee o offre funzionalità di scorrimento orizzontale ai loro IDE CLI?

I monitor da 1920x1080 pixel alla fine diventeranno la norma e gli sviluppatori di tutto il mondo vivono ancora con le stesse limitazioni senza influenzare il motivo per cui lo fanno tranne che è quello che gli anziani hanno detto di fare quando hanno appena iniziato a programmare.

80 limiti di caratteri non sono una buona pratica ma una pratica di nicchia per una minoranza di programmatori e dovrebbero essere trattati come tali.

Modificare:

È comprensibile che a molti sviluppatori non piaccia la barra di scorrimento orizzontale perché richiede un gesto del mouse, quindi ... Perché non aumentare il limite di larghezza della colonna a un numero più alto (di 80) per quelli di noi che usano i display moderni.

Quando i monitor di computer 800x600 sono diventati la norma per la maggior parte degli utenti, gli sviluppatori Web hanno aumentato la larghezza del loro sito Web per soddisfare la maggior parte ... Perché gli sviluppatori non possono fare lo stesso.

Misura, misura, misura

Così bene, misura via, ma per isolare i bug delle prestazioni, la misurazione funziona così come la successiva eliminazione. Ecco il metodo che uso.

Ho cercato di rintracciare la fonte della "saggezza" misura-misura. Qualcuno con una soapbox abbastanza alta l'ha detto, e ora viaggia.

Il mio insegnante mi chiede di iniziare tutti i miei identificatori (escluse le costanti) con lettere minuscole, ad es myVariable.

So che sembra una cosa minore, ma molti linguaggi di programmazione richiedono che le variabili inizino con lettere maiuscole. Apprezzo la coerenza, quindi è mia abitudine iniziare tutto con lettere maiuscole.

Usa Singletons

Quando dovresti avere solo un'istanza di qualcosa. Non posso essere più in disaccordo . Non utilizzare mai un singleton e allocarlo una volta sola e passare il puntatore / oggetto / riferimento secondo necessità. Non c'è assolutamente alcun motivo per non farlo.

Utilizzo di int senza segno come iteratore

Quando impareranno che usare int firmato è molto più sicuro e meno soggetto a bug. Perché è così importante che l'indice di array possa essere solo un numero positivo, che tutti sono felici di trascurare il fatto che 4 - 5 è 4294967295?

I metodi non dovrebbero essere più lunghi di una singola schermata

Concordo pienamente con il principio della responsabilità singola, ma perché le persone lo percepiscono come "una funzione / metodo non può avere più di una singola responsabilità al più alto livello di granularità logica"?

L'idea è semplice Una funzione / metodo dovrebbe svolgere un compito. Se parte di quella funzione / metodo può essere utilizzata altrove, tagliarla nella propria funzione / metodo. Se potrebbe essere utilizzato altrove nel progetto, spostarlo nella propria classe o in una classe di utilità e renderlo accessibile internamente.

Avere una classe che contiene 27 metodi helper che vengono chiamati una sola volta nel codice è stupido, uno spreco di spazio, un inutile aumento della complessità e un enorme dispendio di tempo. Sembra più una buona regola per le persone che vogliono apparire impegnate nel refactoring del codice ma non producono molto.

Ecco la mia regola ...

Scrivi funzioni / metodi per realizzare qualcosa

Se ti trovi in ​​procinto di copiare / incollare del codice, chiediti se sarebbe meglio creare una funzione / metodo per quel codice. Se una funzione / metodo viene chiamata una sola volta in un'altra funzione / metodo, c'è davvero un punto nel farlo in primo luogo (verrà chiamata più spesso in futuro). È utile aggiungere più salti in / out di funzioni / metodi durante il debug (vale a dire, il salto aggiunto rende il debug più facile o più difficile)?

Concordo pienamente sul fatto che funzioni / metodi superiori a 200 righe debbano essere esaminati, ma alcune funzioni svolgono solo un compito in altrettante righe e non contengono parti utili che possono essere astratte / utilizzate sul resto del progetto.

Lo guardo da una prospettiva di sviluppo API ... Se un nuovo utente dovesse guardare il diagramma di classe del tuo codice, quante parti di quel diagramma avrebbero senso all'interno del più grande progetto e quante esisterebbero solo come aiutanti di altre parti interne al progetto.

Se dovessi scegliere tra due programmatori: il primo ha la tendenza a scrivere funzioni / metodi che provano a fare troppo; il secondo rompe ogni parte di ogni funzione / metodo al massimo livello di granularità; Vorrei scegliere le prime mani verso il basso. Il primo otterrebbe di più (ovvero scrivere più carne dell'applicazione), il suo codice sarebbe più facile da eseguire il debug (a causa di un minor numero di salti in / out di funzioni / metodi durante il debug), e perderebbe meno tempo a impegnarsi nel perfezionamento di come il codice sembra vs perfezionare il modo in cui funziona il codice.

Limitare le astrazioni non necessarie e non inquinare il completamento automatico.