È pericoloso avere un file di utilità di grandi dimensioni?

Question

Nel mio progetto C ho un file utils.c piuttosto grande. È davvero pieno di molte utilità di vario genere. Mi sento un po 'impertinente solo a riempire diverse funzioni varie. Ad esempio, ha alcune utilità relative a cose di basso livello come una funzione di lettere minuscole() e ha anche alcune utility piuttosto sofisticate come la conversione in/da diversi formati di colore.

La mia domanda è, è molto cattivo avere un utils.c così grande con molti diversi tipi di utilità in esso? Dovrei suddividerlo in molti diversi tipi di file di utilità? Come graphics_utils.c e così via Cosa ne pensi?

Answer 1

Se sei solo tu che MAI manterrai la roba, è una questione di quando la complessità arriva al punto in cui ti ritrovi a cercare le cose. Quello sarebbe il momento di refactoring e riorganizzazione (c'è un costo da riorganizzare, proprio come c'è un costo per non riorganizzarsi).

Se è possibile che qualcun altro mantenga un progetto che include i propri programmi di utilità, è necessario considerare IL LORO punto di dolore quando si decide quando riorganizzare. Il loro è molto più basso del tuo.

Answer 2

Tendo a suddividerli in vari sub-utils come dici (graphics_utils) quando diventa appropriato.

Answer 3

Spezzarle in file separati in base a categorie (ad esempio grafica, stringhe, ecc.) Porteranno a una migliore organizzazione, semplificando l'individuazione di determinate parti di codice, con file più piccoli da passare, invece di una sola grande file.

Answer 4

Non è sicuramente kosher, perché il prossimo ragazzo che passa attraverso il tuo codice non saprà dove cercare qualcosa. Spezzalo per funzione, e i tuoi colleghi ti ringrazieranno!

Answer 5

Scomposizione. La roba sarà più facile da trovare, più facile da riutilizzare, più facile da refactoring, più facile da testare. Recentemente ho avuto bisogno di ottenere un set di metodi di gestione delle date ISO-8601 da una ginormous classe di utility Java di metodi statici, ed è stato davvero difficile trovare il 5% del codice di cui avevo bisogno.

Answer 6

Come tutti gli altri li interrompo. Ma io tendo ad utilizzare i metodi di estensione ora, quindi avrei una classe (e un file) per classe estesa (ad esempio StringExtensions, SqlDataReaderExtensions, ecc.). Trovo che questo tenda a rompere bene i metodi di utilità.

Answer 7

Si desidera suddividerlo, non solo per motivi organizzativi, ma perché si avranno molti altri file che dipendono da questo. Poiché tutto dipenderà da questo file, rende difficile modificare questo file perché potrebbe causare una rottura diffusa.

http://ifacethoughts.net/2006/04/15/stable-dependencies-principle/

Answer 8

Un altro vantaggio che deriva dalla rottura del file in separa è che quando si posiziona sotto il controllo di origine, è possibile avere un controllo a grana più fine. Questo è davvero utile se si hanno bit aggiornati/estesi/specializzati frequentemente e altri bit relativamente stabili.

Answer 9

Un altro punto: è necessario organizzare il codice, i. e. suddividilo in moduli più piccoli e categorizzalo, perché ad un certo punto nel tempo finirai a scrivere una seconda e una terza funzione per la stessa cosa, semplicemente perché non troverai quella funzione che sapevi che era lì, ma tu non ricordo il suo nome

Ho un progetto (piuttosto grande) con un tale modulo e c'è una logica di programmazione per la quale esistono fino a 5-6 implementazioni (per la stessa cosa).