Convenzioni di denominazione per le variabili [chiuso]

Ci deve sempre essere uno scopo per una variabile, altrimenti puoi lasciarlo fuori e non hai bisogno di un nome. Quindi usa il suo nome per identificare lo scopo di una variabile.

es. A volte introduco variabili al solo scopo di mantenere un valore che deve essere restituito. Potrei chiamare quella variabile returnValue per esempio. a volte è temporaneo per una variabile diversa, potrei usare tempUserName

spero che questo aiuti.

Per me, queste sono le regole di base qualsiasi convenzione dovrebbe basarsi su:

1. Qualsiasi convenzione scelta dovrebbe rendere più facile leggere il codice.
   Ogni riga di codice viene scritta una volta, ma letta decine, centinaia o migliaia di volte. Quindi il tempo necessario per scrivere una riga di codice è irrilevante, importante è solo il tempo necessario per leggere e comprendere una riga di codice. Qualsiasi convenzione dovrebbe avere questo in mente.
2. Sii coerente.
   L'unica cosa peggiore di un mix di convenzioni non è affatto una convenzione e più le convenzioni sono miste, più il primo si avvicina a quest'ultimo.
3. Non inventare la tua convention .
   Di solito, si sta programmando come parte di una squadra, aggiungendo codice ad un progetto che è stato in giro per un po '. Attenersi alle convenzioni del team o del progetto.
   Se stai facendo un progetto da solo, usa una convenzione popolare con i tuoi colleghi o comune nei progetti della tua azienda. Di solito altri si uniranno in seguito o subentreranno alla manutenzione dopo che te ne sei andato. Falli sentire a casa.
   Se sei solo e non hai una squadra o un progetto da considerare (quanto è probabile che, a meno che tu non stia facendo cose da solo e per divertimento?), Scegli una convenzione esistente. Preferisci quelli che sono comuni nel campo in cui lavori.

Le seguenti sono alcune convenzioni specifiche che considero importanti. Se dovessi entrare a far parte di una squadra o di un progetto in cui le convenzioni si erano già stabilite per violarne esplicitamente, avevo iniziato a ribellarmi e a fare un po 'di confusione.

1. Le variabili rappresentano oggetti nel mondo reale, quindi dovrebbero essere nominati con un nome .
2. Tipi rappresentano categorie di oggetti nel mondo reale, quindi anche loro dovrebbero essere nominati con un nome .
3. Funzioni e metodi rappresentano azioni nel mondo reale, quindi dovrebbero essere denominate con verb .
4. I booleani dovrebbero avere un "è", "ha", "deve essere" o qualcosa di simile nel loro nome. Questo è vero sia per le variabili booleane che per le funzioni / metodi che restituiscono i booleani.
5. Non codificare i tipi nei nomi. Nel corso di un decennio di aggiunta di funzionalità e correzione di bug, i tipi cambiano spesso. È maldestro, soggetto a errori e spesso è praticamente impossibile modificare i nomi delle variabili di conseguenza.
6. Evita le abbreviazioni eccetto dove sono veramente ovvie e molto comuni. (Sì, lo so che questo è piuttosto sfocato. Tuttavia, doveva essere detto.)

Sia che si utilizzi PascalCase , camelCase o fake_space_style , sia che gli identificatori inizino con una maiuscola o meno, dove inserire le parentesi ecc., ho le mie preferenze in merito. Ma io considero solo questo: preferenze personali, facilmente annullate dagli accordi specifici del team o del progetto.

Uso snake_case per tutte le mie variabili.

Cerco di renderli belli, specifici e senza inutili abbreviazioni. per esempio. file_id piuttosto che fid.

Se sto provando qualcosa, di solito uso la prima lettera del tipo. per esempio. Se sono nell'interprete Python, userò l per una lista, per la stringa, ecc.

Altrimenti gli do un nome descrittivo.

Ho intenzione di rubare la risposta di jensgram per evitare i conflitti, buona idea.

Due scenari a cui posso pensare:

• Quando si aggiungono funzionalità (hacking) nel codice già disordinato (per qualche motivo questo succede molto nelle estensioni TYPO3) tendo a prefisso le mie variabili con le mie iniziali ( $jgXxx ). Questo mi rende abbastanza sicuro che non sto introducendo conflitti nel codice PHP che nemmeno voglio per capire.

• Quando ho solo bisogno di un segnaposto di solito uso il prefisso $tmpXxx .

Ogni nome di variabile dovrebbe essere "ovvio" nel senso che dovrebbe trasmettere lo scopo della variabile in un modo che sia leggibile e comprensibile. Chiediti "cosa rappresenta questa variabile in termini del problema più grande che sto cercando di risolvere?" La risposta a questa domanda è il nome della variabile.

Non usare nomi come "myVar" o "variable1"; quei nomi non ti dicono nulla su ciò che rappresenta la variabile. E per amore di Dio, fai non perpetuare l'abuso della notazione ungherese che codifica informazioni di tipo primitivo nel nome della variabile (iCounter, szName, fRoot, ecc.) Se puoi aiutarlo. Questo non è ciò per cui è pensato, e ingombra solo il codice e rende i nomi difficili da leggere.

Se devo davvero creare una variabile di cui non ho bisogno (a causa della semantica del linguaggio), uso _ o $_ (dipende dalla lingua). AFAIR è proposto da qualche parte nei PEP di Python.

Altrimenti, come ha affermato KeesDijk, ogni altra variabile ha uno scopo e dovrebbe essere chiamata adeguatamente.

Se hai una convenzione da seguire (una molto comune è usare i, j, k per i loop, altri possono includere nomi come tmp , swap etc) attenersi ad essa.

Personalmente preferisco non usare nomi come tmp - non sono descrittivi. Usa qualcosa di più chiaro, come "rest_to_send", "last_data_pointer" o "current_vertice", invece;)