Tidy First?

Capitolo 3. Normalizzare le simmetrie

Questo lavoro è stato tradotto utilizzando l'AI. Siamo lieti di ricevere il tuo feedback e i tuoi commenti: [e-mail]

Il codice cresce in modo organico. Alcune persone usano "organico" come peggiorativo. Per me non ha senso. Non possiamo scrivere tutto il codice di cui avremo bisogno in una volta sola. Questo funzionerebbe solo se non imparassimo mai nulla.

Nella crescita organica, lo stesso problema può essere risolto in modo diverso in momenti diversi o da persone diverse. Questo va bene, ma rende la lettura difficile. Come lettore, vorresti coerenza. Se vedi uno schema, puoi concludere con sicurezza che sai cosa sta succedendo.

Prendiamo l'esempio delle variabili inizializzate da . Potresti vederle scritte in modi diversi:

foo()
    return foo if foo not nil
    foo := ...
    return foo

foo()
    if foo is nil
        foo := ...
    return foo

# tricky
foo()
    return foo not nil
        ? foo
        : foo := ...

# doubly tricky, assuming assignment is an expression
foo()
    return foo := foo not nil
        ? foo
        : ...

# even trickier, hiding the conditional
foo()
    return foo := foo || ...

(Vedi se riesci a trovare o inventare altre varianti).

Sono tutti modi per dire: "Calcola e metti in cache un valore per pippo, se non l'abbiamo già fatto". Ognuno ha i suoi pro e i suoi contro. Il lettore si abituerà rapidamente a uno qualsiasi di essi. Le cose si confondono quando due o più schemi vengono utilizzati in modo intercambiabile. Come lettore, ti aspetti che la differenza ...