La ridenominazione variabile in tutta la soluzione produrrà un sacco di rumore nella colpa di git. Cosa fare?

3

Ho ereditato 1 milione di righe di codice legacy C ++. In tutto il codice vengono utilizzate variabili come bCPCHAR bPCHAR, bCPDOUBLE e bPINT. Sono definiti in questo modo:

  • bCPCHAR : const char *
  • bPCHAR : char *
  • bCPDOUBLE : const double *
  • bPINT : int *

Stavo pensando di rimuovere questo livello di riferimento indiretto, soprattutto perché bCPCHAR e bPCHAR vengono mescolati nel codice molto spesso e sono molto più difficili da leggere rispetto a const char * e char * . Ma un collega ha sottolineato che questo cambiamento genererà molto rumore in colpa. Quale penso sia un punto valido.

Penso di non essere la prima persona con questo problema. C'è una soluzione? Puoi darmi qualche consiglio?

Pulisci codice dallo zio Bob non mi ha aiutato; -)

    
posta Dominic Hofer 23.12.2017 - 16:49
fonte

2 risposte

10

Non sono d'accordo che si tratti di un contro-argomento.

blame mostra chi ha l'ultima riga di codice modificata, non perché o in che misura. Questa è una debolezza strutturale, non risolvibile in blame , e chiunque la utilizzi deve essere consapevole di non fare ciò che preferirebbe (fornire una comprensione di alta qualità della storia di una base di codice), non importa quanto loro lo desiderano Questo tipo di narrazione di alto livello del progetto deve essere trasmesso attraverso altri canali nel flusso di lavoro del progetto. Certamente non dovresti mai cambiare le tue pratiche di codifica per soddisfare questa assunzione fondamentalmente errata e sbagliata.

    
risposta data 23.12.2017 - 19:21
fonte
5

Un'opzione consiste nell'applicare le modifiche che descrivi e vivere con una rumorosa dose di git per un po ', perché, presumibilmente, dopo qualche tempo diventerà meno rumoroso.

Un altro consiste nell'applicare queste modifiche nel tempo, come un processo di lunga durata, ad es. come fase preparatoria, di portata limitata, prima di iniziare a lavorare su una nuova funzione.

In ogni caso, questo potrebbe essere utile: Git blame - precedenti commit?

    
risposta data 23.12.2017 - 18:29
fonte

Leggi altre domande sui tag