Qui ci sono molte risposte che affrontano i pro ei contro tecnici di tenere giù LOC e se si tratta di una metrica del software di qualità significativa. Non è di questa domanda. Si tratta di come affrontare la gestione che insiste su un'ingenua aderenza dogmatica a una particolare regola empirica della codifica.
Purtroppo, è abbastanza comune per le persone aggrapparsi a cose che sono buoni consigli quando usate nel contesto appropriato e applicate pragmaticamente, portarle fuori da quel contesto e applicarle dogmaticamente senza riuscire ad apprezzare i problemi che il consiglio esiste per mitigare in il primo posto.
L'intento del consiglio di mantenere LOC giù è di evitare la creazione di metodi che cercano di fare troppo in una volta, e di scoraggiare la creazione di "divinità", che sanno troppo su aspetti di un design che non sono sono la loro diretta responsabilità e da cui dipendono tutte le altre classi del sistema. Un altro vantaggio del codice più breve è che è più leggibile, anche se come hai sottolineato, puoi esagerare fino al punto in cui la leggibilità inizia effettivamente a soffrire.
Ci sono ovvi vantaggi per i bassi conteggi di LOC (piccoli metodi si adattano alla tua testa più facilmente di quelli grandi, meno cose nel codice significano meno cose da sbagliare, ecc.), ma è anche soggetto alla legge dei rendimenti decrescenti . Il refactoring di un metodo a 150 linee in un numero di 20 metodi di linea è una vittoria molto più grande rispetto al refactoring di un metodo a 10 linee in un metodo a 7 linee.
Quando tale refactoring viene a scapito di qualche altro aspetto del buon design del software (come la leggibilità), allora hai raggiunto un punto in cui puoi giustificare di non farlo. Rimuovere le variabili che danno un contesto a ciò che il codice significa e sostituirle con letterali che non lo sono è una cosa molto brutta da fare. Il buon codice non ha quasi letterali in esso. Tuttavia, queste variabili (e le costanti nominate) sono linee di codice che non contribuiscono direttamente al programma e quindi se LOC viene adorato come una sorta di dio, allora tali linee di chiarimento sono in grave pericolo di essere potate per una rapida vittoria e qualche elogio fuorviato da parte della direzione.
Credo che tu sia abbastanza intelligente per rendertene conto, in effetti questo è praticamente l'essenza della tua domanda originale. Il problema non è la vostra comprensione di quando la riduzione del codice è buona e quando non lo è, il problema è il dogmatismo nell'applicare ciò che normalmente è una pratica ragionevole indiscriminatamente.
Consiglierei di dedicare del tempo a chattare con la tua direzione, spiegando la tua posizione e il motivo per cui ritieni che ciò che ti viene chiesto di fare danneggi il codice piuttosto che aiutarlo. Cerca di evitare di essere conflittuale, ma cerca di rimanere razionale e calmo durante questa discussione. È importante che il management capisca che la programmazione è un'attività pragmatica e che i consigli sulle best practice sono utili solo se applicati in modo pragmatico. La migliore pratica è scritta in un libro, non scolpita nella pietra, e quando è in conflitto (codice corto o codice leggibile), spetta al programmatore applicare il proprio giudizio su quale migliore pratica seguire. Speriamo che siano persone ragionevoli che apprezzano l'input come questo.
Devi anche essere un po 'coraggioso, perché se sei sotto pressione per ridurre LOC dove pensi che sia inutile o inappropriato, allora è naturale che tu faccia il resto comunque per una vita tranquilla. Devi resistere a fare questo, e devi "possedere" quella decisione. In una situazione in cui la gestione è ragionevole, non dovresti rispettare esattamente le loro linee guida, ma dovresti essere in grado di giustificare le circostanze in cui non lo sei.
Tristemente, le persone possono essere irrazionali, specialmente quando si tratta di persone che non rispettano l'ordine gerarchico che mettono in discussione le loro decisioni e le regole che ti hanno imposto. Possono scegliere di non essere ragionevoli. Devi essere preparato anche per questo. Se è possibile dimostrare casi in cui la migliore pratica di LOC entra in conflitto diretto con altre migliori pratiche e perché questo danneggia il prodotto, e se lo si può fare in porzioni della base di codice per cui hanno avuto poco o nessun coinvolgimento personale (quindi non sembra un attacco personale al loro lavoro o al loro lavoro supervisionato), quindi questo potrebbe aiutare a rafforzare la tua argomentazione. Ancora una volta, devi essere pronto a giustificarti in modo calmo, razionale ed essere in grado di "possedere" gli argomenti che stai facendo.
Se la tua gestione è composta da persone ragionevoli, allora devono comprendere che ciò che dici è un merito se puoi fornire prove a sostegno delle tue richieste.