Scrittura del codice leggibile e non esagerare con la denominazione [chiuso]

Question

Scrittura del codice leggibile e non esagerare con la denominazione [chiuso]

#1 da (1 voti)
#2 da (0 voti)

-3

Sono stato in una discussione al lavoro sulla scrittura di codice leggibile. Si trattava principalmente di nomi di variabili e metodi e l'idea che i commenti non hanno valore se il codice è sufficientemente leggibile. Non vorrei sottolineare solo su nessun linguaggio di programmazione specifico.

1.) Nomi descrittivi vs variabili e metodi descrittivi I nomi descrittivi delle variabili sono più facili da comprendere per i principianti, mentre quelli minimalistici semplificano la navigazione nel codice (Nessuno schermo ingombra di nomi lunghi di cammello) Diciamo che ho un metodo:

convertOneFormatToAnotherFormat () vs oneFormatToAnother ()
checkIfTypeIsBoolean () vs isBoolean
rerenderNavigationInNavbar vs refreshNavbar ()

Che cosa diresti che una buona regola è?

2.) Uso delle abbreviazioni per la denominazione delle variabili e l'utilizzo di nomi completi ogni volta Le abbreviazioni rendono il tuo codice meno ingombrante, mentre i nomi completi rendono più facile la comprensione. Il punto dell'argomento era che ho detto che alcune abbreviazioni sono meglio di fullNames. Consente di controllare gli esempi stupidi:

JSON vs javascriptObjectNotation
RGB vs redGreenBlue
VB vs visualBasic

Delle abbreviazioni di couse sono migliori.

conv vs convert
dev vs sviluppatore
usr vs utente

I nomi completi sono sicuramente meglio qui. Vorrei chiedere obiezioni qui per alcuni esempi poco chiari:

kvp vs keyValuePair
ddl vs dropDownList

Cosa sceglieresti qui? Inoltre, come scriveresti una regola per nominare abbreviazioni?

3.) Commenti non necessari se il codice è sufficientemente leggibile C'è uno standard che dice che la documentazione e i commenti non sono necessari se il codice è sufficientemente leggibile. Eppure ho scoperto che ho fatto delle scelte specifiche nel mio codice e volevo spiegare le mie scelte nei commenti sopra.

Vuoi dire che i commenti nel codice che spiegano la logica sono necessari?
Diresti che i commenti che segmentizzano solo il codice sono necessari?
Vuoi documentare l'HTML con i commenti? Orità (tag adolescente, μ tag iniziali (,)

4.) Nome breve nella funzione standalone breve vs nomi significativi Diciamo che ho un metodo che trova restituisce un numero e lo moltiplica per 2 Va bene per:

multiplyByTwo(x):
    a = x*2
    return a

o è molto meglio:

multiplyByTwo(factor):
    result = factor*2
    return result

So che il modo migliore è essere intelligenti e utilizzare quello che informa il lettore e rende il suo lavoro il più semplice possibile è il migliore, ma per i team questo è difficile da fare poiché ognuno ha il suo stile.

Grazie per la risposta

coding-standards naming naming-standards

posta IamSneaky 05.12.2017 - 13:27

fonte

2 risposte

Leggi altre domande sui tag coding-standards naming naming-standards

C #. Modello per la creazione dinamica di report Implementazione del codice funzionale / riutilizzabile [chiuso]

score 1 · Answer 1

Proprio come ogni altro linguaggio è spesso dato dal contesto e dalla storia.

per esempio ddl è un'abbreviazione comune per l'elenco a discesa in alcuni contesti ma non in altri. Se provieni da uno sfondo VB6, puoi usare invece comboBox.

La filosofia della codifica pulita ti farà dimenticare completamente i commenti, ma secondo me è piuttosto ristretta. Dipende dal fatto che tutti hanno la stessa visione di "leggibilità". Se hai lavorato con sviluppatori che non parlano inglese o sistemi con una terminologia strana, saprai che i nomi lunghi non sempre spiegano cosa sta facendo il codice.

Proprio come hai scoperto con il tuo collega, ciò che una persona trova leggibile un'altra no.

Quindi in generale. Sì, evita myFunc(x) e //adding two to the number ma non impazzire. Una combinazione di commenti e nomi più lunghi ti vedrà, ad esempio,

///
///convert incoming JSON data into Data object so that we can blah blah
///
Data ParseJson(string json) {...}

score 0 · Answer 2

1.) Descriptive vs minimalistic variable and method names Descriptive variable names are easier for a newcommer to understand while minimalistic makes it easier to navigate your code (No screen cluttered with long camelCase names) Lets say i have a method:
convertOneFormatToAnotherFormat() vs oneFormatToAnother()
checkIfTypeIsBoolean() vs isBoolean
rerenderNavigationInNavbar vs refreshNavbar()
What would you say a good rule is?

All'inizio dovrebbero seguire le convenzioni di denominazione che (in Java) includono che i nomi dei metodi iniziano sempre con un verbo .

Quindi l'esempio è un po 'sciocco perché è (intenzionalmente) generico. Ma che dire di questo?

convertXmlToJson()

2.) Using abbrevations for variable naming vs using full names everytime

JSON vs javascriptObjectNotation

RGB vs redGreenBlue

VB vs visualBasic

Direi che usare (molto) comuni acronimi è OK.

Ma

Of couse abbrevations are better.

conv vs convert

dev vs developer

usr vs user

Full names are better here for sure. I would like to ask for oppinions here for some more unclear examples:

kvp vs keyValuePair

ddl vs dropDownList

le abbreviazioni non sono affatto buone.

3.) Comments not needed if code is readable enough

I commenti dovrebbero spiegare perché il codice è come è. Per esempio. perché preferivi una certa sintassi o struttura rispetto ad un'altra, più comune (all'interno della tua base di codice) ...

Anche le interfacce di solito hanno bisogno di commenti per aiutare l'implementatore a capire il contratto dietro di esso.

Would you say comments in code that explain logic are needed?

No

Would you say that comments that only segmentize the code are needed?

No

Would you document HTML with comments? (End tags, beginning tags (, )

No (ho strumenti con evidenziazione corretta)

4.) Short names in short standalone function vs meaningfull names

È un caso speciale dell'emissione abbreviazione ...