Qual è una buona pratica di codice quando creare una funzione / metodo per piccoli segmenti di codice ripetitivi?

Molte volte durante la scrittura di programmi più grandi ho messo in dubbio dopo quante copie e paste ha senso mettere il codice in una funzione o metodo e qual è una buona regola empirica? Ho usato una regola empirica di quattro o più righe e ho visualizzato più di due volte, quindi creo una semplice funzione / metodo contenente quel codice. Riesci a pensare a una pratica migliore o offrire qualche suggerimento? Questa è più una domanda di modello di progettazione generale piuttosto che una domanda specifica della lingua.

Uso le funzioni in parte come modo per documentare il codice. La chiamata di una funzione con un nome significativo semplifica la comprensione del codice. In alcuni casi anche una funzione con una sola riga ha senso.

Ad esempio, in "Codice pulito", Robert C. Martin fornisce il seguente esempio: quale preferiresti vedere? Questo:

// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
    (employee.age > 65))

O questo?

if (employee.isEligibleForFullBenefits())

Non sono sempre d'accordo con lui, ma in questo caso lo faccio. Il codice dovrebbe essere leggibile, non solo quando lo scrivi e conosci ogni dettaglio, ma anche alle 21:00 quando devi correggere i bug nel codice di qualcun altro. Non è raccomandato fissare una condizione lunga e cercare di capire tutti i doppi negativi. Se puoi semplicemente inserire un nome (non solo le condizioni, ma ogni parte di codice che scrivi), diventa molto più semplice.

Non mi sono mai pentito di aver inserito qualcosa in una funzione, e se sei preoccupato per le prestazioni, allora prima profilo.

Esiste un malinteso diffuso sul fatto che le chiamate di funzione dovrebbero essere effettuate solo per evitare segmenti di codice ripetitivi. La mia regola empirica è che qualsiasi unità logica di lavoro dovrebbe essere trasformata in una funzione, anche quando viene utilizzata solo in un unico posto. Questo di solito porta a una migliore leggibilità e ti consente di scrivere codice autocompattante, in cui i nomi delle funzioni sostituiscono i commenti e non è necessario scrivere commenti aggiuntivi che spieghino cosa stai facendo.

Se viene utilizzato in più di un posto, e

• è probabile che cambi, o
• è difficile avere ragione

quindi renderlo una funzione o un metodo. Pezzi lunghi di codice ripetuto, nella mia esperienza, ricadranno naturalmente in una di queste categorie (di solito la prima, ma poi le categorie si sovrappongono molto;). Naturalmente, tutto ciò che deve essere nell'interfaccia è anche una funzione / metodo a sé stante.

Quasi sempre, soprattutto se ogni duplicato rappresenta la stessa operazione da un punto di vista concettuale. Se viene eseguito allo stesso modo, ma su tipi diversi, eseguire un'implementazione generica.

L'unico motivo per cui non mi viene in mente è quello della manutenzione: a volte potrebbe essere più conveniente evitare di creare una dipendenza tra cose separate, anche a costo di una duplicazione.

Una ricerca di " refactoring " ti porterà a molte risorse per "best practice" del settore per questo processo molto comune. L'articolo un po 'famoso, Once and Only Once è un grande riferimento storico che spiega quali alcuni considerano "buone pratiche" per le preoccupazioni sollevate dalla tua domanda. Inoltre, il concetto ancora più generale è noto come Don't Repeat Yourself (DRY) . Per una serie davvero approfondita di risposte alla tua domanda, leggi il grande classico di Martin Fowler , Refactoring: Improving the Design of Existing Code , che copre alcuni dei consigli più noti per il refactoring , che è ciò che stai cercando intuitivamente di realizzare !

Se il codice viene ripetuto esattamente in più di una volta e la sezione ripetuta non cambierà nel prossimo futuro, lo interrompo in una funzione.

Ciò dipende dalla natura della coesione del codice ripetuto. Se la sezione ripetuta del codice esegue una funzione specifica, allora è un ottimo candidato per essere trasformato in un metodo, in parte a causa del principio DRY , in parte perché se la funzione deve essere ottimizzata o corretta, allora c'è solo una sezione di codice da affrontare.

Se l'associazione è una coincidenza, è meglio ripetere il codice piuttosto che trasformarlo in un metodo. Se devi aggiungere qualcosa al centro di una delle sequenze di codice per soddisfare uno degli usi di quello snippet, se si trova in un metodo, la modifica apportata potrebbe influire su altri usi di quel metodo.

Vedi l'articolo di Wikipedia sul concetto di coesione del codice .

Devi distinguere tra funzioni nel senso della programmazione strutturata e metodi di una classe.

Nel tuo esempio, quello che hai mostrato è un metodo e come tale non dovrebbe essere codificato in linea.

potresti dover convalidare una stringa per vedere se è un numero oppure no, in questo caso usi una funzione e si applicano la maggior parte delle risposte precedenti.

Questa distinzione è importante specialmente nei grandi progetti.

Per quanto è possibile, cerca di separare le regole di business (che sono metodi) dagli algoritmi di elaborazione (che sono pure funzioni di programmazione).