Avere una sezione general_code è una cattiva idea?

Question

Avere una sezione general_code è una cattiva idea?

#1 da (6 voti)
#2 da (1 voti)

1

Sto lavorando su un piccolo progetto python e ho un file general_code.py dove ho le funzioni che uso nel progetto. Alcuni esempi:

def to_boolean(var):
    return var in ['True', 'true', '1', 'y', 'Y' 'yes', 'Yes']

e.g 2

def get_last_line(in_file, block_size=128, ignore_ending_newline=False):

e.g 3

def signal_handler(log, self, signum, frame):  # pragma: no cover
    log.info("Ctrl + C pressed. Exiting application gracefully")
    self.run = False
    while threading.active_count() > 1:
        time.sleep(1)
    log.info("All threads closed. Exit.")
    sys.exit(0)

per esempio 4.

class Timer(object):  # pragma: no cover
    def __init__(self, name=None):
        self.name = name

    def __enter__(self):
        self.tstart = time.time()

    def __exit__(self, type, value, traceback):
        if self.name:
            print('[%s]' % self.name,)
        print('Elapsed: %s' % (time.time() - self.tstart))

e.g 5

def get_file_version(log, filename=None):

e.g 6

def setup_logger(filename):

È un buon design avere un posto così centrale per funzionalità comuni? Mi è servito bene, ma spesso idee che potrebbero essere grandiose in un piccolo ambito possono finire in progetti terribili o ambiti diversi. Quindi quale sarebbe un buon modo in Python per raggruppare le funzionalità comuni? Avere tutte le funzioni semplicemente in un file come faccio bene o sarebbe meglio metterle tutte in una classe o qualcosa di completamente diverso?

design-patterns

posta Hakaishin 11.09.2018 - 10:04

fonte

2 risposte

1

Avere file di codice comuni non è una cattiva idea, ma è pericoloso. Non è una soluzione ideale, ma è così comune e semplice che è strongmente utilizzata nella maggior parte dei progetti reali. È necessaria molta disciplina per evitare che i file comuni facciano troppe cose, diventando una lezione di Dio e rendendo il tuo codice molto più confuso. Un file comune dovrebbe essere una dimora di ultima istanza per le funzioni e non dovrebbe mai avere funzioni che fanno la logica aziendale. Un altro trabocchetto comune è la creazione di funzioni in un file comune che non sono in realtà comuni, questo in genere è dovuto al tentativo di ridurre la duplicazione in modo aggressivo. Questo generalmente si manifesta in avere una funzione come: foo(); foo2(); foo3(); o avere una funzione con molti parametri che sono per lo più opzionali. Se rimani disciplinato nella tua codifica, un file di codice comune può essere un ottimo strumento, ma può diventare un incubo se non stai attento.

risposta data 11.09.2018 - 14:23

fonte

Leggi altre domande sui tag design-patterns

È meglio imparare html, javascript, php, quindi mysql se vuoi iniziare il tuo sito? [chiuso] Ottimizzazione del ciclo iterativo con elementi rimossi

score 6 · Accepted Answer

Può andare bene per casi d'uso più piccoli, anche se non è l'ideale. Se hai 3 o più funzioni di utilità, è gestibile nella tua testa per tenerle in un file, ma rapidamente diventa fuori controllo ed è pressoché impossibile navigare in un file di dio con 200 funzioni di utilità in cui alcune sono correlate e altre no ( troppo carico cognitivo).

Mi piacerebbe senz'altro fare un solo file "general code": il nome dell'importazione non fornisce alcuna informazione su cosa sta facendo e, man mano che un progetto cresce, potrebbe essere un file importato in tutto (e dovendo essere usato ovunque, possono essere estesi fino a quando non si hanno una dozzina di flag opzionali su ogni funzione in modo da poter ottenere i ritorni giusti).

Come soluzione che aiuta a gestirlo, suggerisco di spostare le funzionalità raggruppate nei propri file. Quindi potresti avere un file "file_utils.py" che contiene exapmles 2 e 5, un file "debug_utils.py" che contiene 4 e 6, "signal_utils.py" che contiene 3 e un "input_parsing_utils.py" che contiene 1 Ciascuno di questi è quindi pacchetti di funzionalità ben confezionati in modo da poter avere esattamente la funzionalità di cui hai bisogno e sono facilmente estensibili. Più in generale, si desidera ottenere gruppi di funzionalità strettamente correlate inserite in gruppi reali e si desidera mantenere tutto ciò che non è correlato a tali funzioni completamente fuori dalla portata (lontano dagli occhi, lontano dalla mente).

Come bonus aggiuntivo, le serie di funzionalità sono separate, quindi se finisci per avere bisogno di un sacco di flag per una funzione, puoi facilmente estrarla in uno schema di fabbrica o di strategia.

Idealmente, questi file di utilità dovrebbero essere totalmente indipendenti l'uno dall'altro (un util non dovrebbe aver bisogno di un altro util per funzionare - se lo fa, probabilmente non è un util). Imballare pacchetti di funzionalità discreti che possono essere estesi o rifattorizzati senza dover toccare altre funzionalità non correlate è una buona cosa. È anche degno di nota il fatto che le cose dovrebbero essere solo utilità se hanno il potenziale per essere riutilizzate - se scrivi una funzione che fa una cosa molto specifica per un interno del sistema e ha bisogno di restituire valori in un formato molto specifico, probabilmente non è vale la pena di fare un'utilità (solo una funzione ish privata sulla classe che ne ha bisogno).