Dovresti usare "abbreviazioni interne" nei commenti al codice? [chiuso]

No, tratta i commenti come parte del codice, il codice dovrebbe essere chiaro a chiunque debba leggerlo, quindi non usare nulla dove dovrebbero indovinare il significato. La chiarezza supera la brevità.

No.

I programmatori non scrivono, comunicano . "Meno codice da digitare" non è un fattore da prendere in considerazione. Invece, come suggerisce @Carnotaurus, considera come puoi migliorare la chiarezza e la leggibilità del tuo codice.

Mi sembra che se c'è una abbreviazione o gergo comune per una risorsa interna , come DW per data warehouse , allora dovrebbe essere ok purché tutti, almeno culturalmente , accetta l'abbreviazione.

Ma al di fuori delle abbreviazioni e del gergo come NYI per Not Yet Implemented rientrano nella stessa categoria come LOL poiché hanno la tendenza a cambiare e cadere dentro e fuori moda rapidamente nel tempo. NYI potrebbe altrettanto facilmente essere NYS per Not Yet Started o NYR per Not Yet Released .

Secondo me se l'abbreviazione è ben nota tra i membri del team di progetto è ok usarla nei commenti di codice perché anche se un nuovo sviluppatore viene assunto, lui / lei saprà sempre cosa significa dagli altri membri.

OTOH, se sei l'unico sviluppatore e non è il tuo progetto personale o se sai che i tuoi compagni di squadra non sanno cosa significa, non usarlo.

Userei solo le abbreviazioni che sono comuni nel dominio. In finanza, ci sono molte risorse per identificare l'EBITDA. La maggior parte delle persone coinvolte nel progetto, anche al di fuori del team di sviluppo, lo capirebbe. Non c'è alcun vantaggio e molti svantaggi.

Neanche io sono appassionato di abbreviazioni linguistiche. È normale usare cn (almeno negli esempi di codice) come connessione, ma mi piacerebbe saperne un po 'di più.

Un esempio del motivo per cui l'uso di abbreviazioni come questa è nel tuo esempio. Hai digitato "NYE" quando intendevi "NYI". Quindi stai dicendo alla gente della notte di capodanno, a quanto pare. Tuttavia, se scrivete "non ancora implementato", otterrebbero comunque l'idea, mentre pensate semplicemente che non si può scrivere.

La codifica non è una gara, quindi non credo che "salvare le battiture" sia una considerazione valida. L'obiettivo dell'esercizio è scrivere un codice pulito e comprensibile e questo si estende a qualsiasi commento "necessario" nel suddetto codice. Analizzando un abbrev. è solo un po 'più faticoso di leggere quello che dice (che in pratica fa automaticamente, senza alcuno sforzo).

C'è una sola abbreviazione ^* che può essere usata nei commenti:

// TODO :

è facile da grep e locate.

^{* O qualcosa di simile.}