Come denominate le vostre librerie personali? [chiuso]

Prova a raggruppare le funzioni di supporto tematiche e includere il tema nel nome della libreria. Un nome di libreria come "helper" può essere troppo generico, ma un nome come "PathHelper", "FileIOHelper" dice praticamente su quali funzioni ci si può aspettare in quella lib (personalmente, preferisco "... Utilities", ma questo è solo una questione di gusti personali). Ad esempio, ho nomi di lib come "MathUtilities", "StringUtilities" "ConfigUtilities", "DBUtilities" e così via.

Ovviamente, per le biblioteche più grandi nel nostro team usiamo nomi senza alcun termine generico alla fine. E per essere onesti, abbiamo anche una libreria chiamata "Comune" per alcune funzioni e classi che non si raggruppano bene sotto un nome di argomento specifico. Ma proviamo a mantenere quella lib piccola.

Generalmente, è un processo organico per me.

I miei spazi dei nomi tendono a rispecchiare i nomi delle mie cartelle, principalmente perché penso che sia più facile trovare le cose in questo modo.

I progetti aziendali hanno generalmente un prefisso aziendale di fronte allo spazio dei nomi, e per i progetti personali si alterna tra project-prefix.folder e solo cartella per i nomi.

Le cartelle "principali" tendono ad essere ovvie per il loro nome e sono generalmente correlate alla loro funzione: "Pippo". Per i progetti più grandi, aprirò la cartella principale per riflettere il principale paradigma di programmazione che potrei seguire. Quindi per MVVM avrei "Foo.View", "Foo.ViewModel" e "Foo.Model" come nomi di esempio.

Invariabilmente, le funzioni di supporto che non si adattano da nessun'altra parte iniziano a insinuarsi nel progetto. Inizierò con una cartella di tipo "comune" o "utilità" per atterrare prima di tutto. "Helpers", "Base" e "Core" funzionerebbero altrettanto bene per un atterraggio iniziale.

Cerco di assegnare un nome alle mie funzioni in base all'oggetto e / o all'azione che eseguono. Quindi potrei avere PathManager, PathChecker, ecc ... Spesso, so che avrò diverse azioni relative a un argomento, quindi chiamerò la classe dopo l'Oggetto e aggiungerò i metodi secondo necessità. Un thesaurus può tornare utile qui.

Ho trovato un'alta correlazione tra la facilità di nominare un oggetto e quanto bene posso descrivere ciò che la funzione dovrebbe fare. Uno dei miei punti di controllo personali è che se faccio fatica a nominare qualcosa, allora questo significa che ho bisogno di riflettere su ciò che la funzione dovrebbe effettivamente fare. Una volta risolti i problemi di funzionalità, il nome viene facilmente.

Man mano che raccolgo più funzioni di supporto, le migrerò nella loro cartella e / o spazio dei nomi. Se ottengono una cartella dal progetto root o se ottengono una sottocartella nella cartella dell'utilità dipende dalla natura e dalla quantità delle funzioni.

Analogamente a GlenH7, tendo ad avere una libreria "-misc", dove org è un'abbreviazione di tre o quattro lettere per chiunque sia il mio attuale datore di lavoro.

Tutte le nuove funzioni casuali vengono messe lì fino a quando non si sono accumulate abbastanza di esse per far emergere un modello. A quel punto, li raggruppo insieme ed estrae le relative funzioni in librerie con un nome più ragionevole, rifattando il codice client secondo necessità.

A volte è stato necessario un po 'di disciplina per mantenere la dimensione della libreria gestibile, ma in questi giorni le mie librerie * -isc tendono a rimanere piuttosto piccole.

(Ho anche sempre una libreria "devauto" e una "testauto" che contengono funzioni "meta-livello" per supportare lo sviluppo e l'automazione dei test).

Anch'io sono molto cattivo in questo. Il mio approccio pragmatico è quello di utilizzare il nome per data e / o progetto e / o posizione, fino a trovare un nome ragionevole.

So che per un'altra persona è impossibile leggere, ma io stesso posso riconoscerle rapidamente. E la maggior parte di queste librerie finisce per uso singolo comunque per me.

Se fossi in me, avrei solo una libreria di percorsi (molto più probabilmente sarebbe una libreria di file system che conteneva un componente di percorso). Fornirebbe l'interfaccia esatta di cui ho bisogno per portare a termine il lavoro. Sicuramente il 90% di esso sarebbe un sottile involucro attorno a boost.filesystem o qualunque linguaggio lib di filesystem esistesse, ma il mio codice vedrebbe sempre questa bella libreria coerente. Nessun tentativo di ricordare se quella funzione fosse in X, X-helper, X-utils o X-ext. Se X ha bisogno di aiuto, è ora di andare a riparare X, non inventare nuove posizioni casuali per il codice.