Convenzione di denominazione (programmazione) - Naming convention (programming)

Nella programmazione per computer , una convenzione di denominazione è un insieme di regole per la scelta della sequenza di caratteri da utilizzare per gli identificatori che denotano variabili , tipi , funzioni e altre entità nel codice sorgente e nella documentazione .

I motivi per utilizzare una convenzione di denominazione (invece di consentire ai programmatori di scegliere qualsiasi sequenza di caratteri) includono quanto segue:

• Ridurre lo sforzo necessario per leggere e comprendere il codice sorgente;
• Per consentire alle revisioni del codice di concentrarsi su questioni più importanti della sintassi e degli standard di denominazione.
• Consentire agli strumenti di revisione della qualità del codice di concentrare i propri rapporti principalmente su questioni significative diverse dalla sintassi e dalle preferenze di stile.

La scelta delle convenzioni di denominazione può essere una questione enormemente controversa, con i partigiani di ciascuno che ritengono i propri i migliori e gli altri inferiori. Colloquialmente, si dice che questa sia una questione di dogma . Molte aziende hanno anche stabilito la propria serie di convenzioni.

Potenziali vantaggi

Alcuni dei potenziali vantaggi che possono essere ottenuti adottando una convenzione di denominazione includono quanto segue:

• fornire ulteriori informazioni (ad es. metadati ) sull'uso a cui è destinato un identificatore;
• aiutare a formalizzare le aspettative e promuovere la coerenza all'interno di un team di sviluppo;
• per consentire l'uso di refactoring automatizzato o strumenti di ricerca e sostituzione con il minimo potenziale di errore;
• migliorare la chiarezza nei casi di potenziale ambiguità;
• per migliorare l'aspetto estetico e professionale del prodotto di lavoro (ad esempio, vietando nomi eccessivamente lunghi, nomi comici o "carini" o abbreviazioni);
• per evitare "collisioni di nomi" che potrebbero verificarsi quando il prodotto di lavoro di diverse organizzazioni viene combinato (vedi anche: namespace );
• fornire dati significativi da utilizzare nei passaggi di progetto che richiedono la presentazione del codice sorgente del programma e di tutta la documentazione pertinente;
• per fornire una migliore comprensione in caso di riutilizzo del codice dopo un lungo intervallo di tempo.

Sfide

La scelta delle convenzioni di denominazione (e la misura in cui vengono applicate) è spesso una questione controversa, con i partigiani che ritengono il loro punto di vista il migliore e gli altri inferiori. Inoltre, anche con convenzioni di denominazione note e ben definite, alcune organizzazioni potrebbero non rispettarle in modo coerente, causando incoerenza e confusione. Queste sfide possono essere esacerbate se le regole della convenzione di denominazione sono internamente incoerenti, arbitrarie, difficili da ricordare o altrimenti percepite come più gravose che vantaggiose.

leggibilità

Identificatori ben scelti rendono molto più facile per sviluppatori e analisti capire cosa sta facendo il sistema e come correggere o estendere il codice sorgente da applicare per nuove esigenze.

Ad esempio, sebbene

 a = b * c;

è sintatticamente corretto, il suo scopo non è evidente. Contrasta questo con:

 weekly_pay = hours_worked * hourly_pay_rate;

che implica l'intento e il significato del codice sorgente, almeno per coloro che hanno familiarità con il contesto dell'affermazione.

Gli esperimenti suggeriscono che lo stile dell'identificatore influenza il richiamo e la precisione e che la familiarità con uno stile accelera il richiamo.

Elementi comuni

Le regole esatte di una convenzione di denominazione dipendono dal contesto in cui vengono impiegate. Tuttavia, ci sono diversi elementi comuni che influenzano la maggior parte se non tutte le convenzioni di denominazione di uso comune oggi.

Lunghezza degli identificatori

Elementi fondamentali di tutte le convenzioni di denominazione sono le regole relative alla lunghezza dell'identificatore (ovvero il numero finito di singoli caratteri consentiti in un identificatore). Alcune regole impongono un limite numerico fisso, mentre altre specificano euristiche o linee guida meno precise.

Le regole sulla lunghezza degli identificatori sono regolarmente contestate nella pratica e soggette a molti dibattiti accademici.

Alcune considerazioni:

• identificatori più brevi possono essere preferiti come più opportuni, perché sono più facili da digitare (sebbene molti IDE e editor di testo forniscano il completamento del testo, che lo mitiga)
• identificatori estremamente brevi (come "i" o "j") sono molto difficili da distinguere in modo univoco utilizzando strumenti di ricerca e sostituzione automatizzati (sebbene questo non sia un problema per gli strumenti basati su espressioni regolari)
• gli identificatori più lunghi possono essere preferiti perché gli identificatori brevi non possono codificare abbastanza informazioni o sembrano troppo criptici
• gli identificatori più lunghi possono essere sfavoriti a causa del disordine visivo

È un problema di ricerca aperto se alcuni programmatori preferiscono identificatori più brevi perché sono più facili da digitare, o pensare, rispetto agli identificatori più lunghi, o perché in molte situazioni un identificatore più lungo ingombra semplicemente il codice visibile e non fornisce alcun beneficio aggiuntivo percepito.

La brevità della programmazione potrebbe essere in parte attribuita a:

• i primi linker che richiedevano che i nomi delle variabili fossero limitati a 6 caratteri per risparmiare memoria. Un "avanzamento" successivo ha permesso di utilizzare nomi di variabili più lunghi per la comprensibilità umana, ma in cui solo i primi caratteri erano significativi. In alcune versioni di BASIC come TRS-80 Level 2 Basic, erano consentiti nomi lunghi, ma solo le prime due lettere erano significative. Questa funzione consentiva un comportamento errato che poteva essere difficile da eseguire il debug, ad esempio quando venivano utilizzati nomi come "VALUE" e "VAT" che dovevano essere distinti.
• primi editor di codice sorgente privi di completamento automatico
• i primi monitor a bassa risoluzione con lunghezza di riga limitata (ad es. solo 80 caratteri)
• gran parte dell'informatica ha origine dalla matematica, dove i nomi delle variabili sono tradizionalmente solo una singola lettera

Caso delle lettere e numeri

Alcune convenzioni di denominazione limitano la visualizzazione delle lettere in maiuscolo o minuscolo. Altre convenzioni non limitano le lettere maiuscole, ma allegano un'interpretazione ben definita basata sulle lettere maiuscole. Alcune convenzioni di denominazione specificano se è possibile utilizzare caratteri alfabetici, numerici o alfanumerici e, in caso affermativo, in quale sequenza.

Identificatori di più parole

Una raccomandazione comune è "Utilizzare identificatori significativi". Una singola parola potrebbe non essere significativa o specifica come più parole. Di conseguenza, alcune convenzioni di denominazione specificano regole per il trattamento di identificatori "composti" contenenti più di una parola.

Poiché la maggior parte dei linguaggi di programmazione non consente spazi bianchi negli identificatori, è necessario un metodo per delimitare ogni parola (per rendere più facile per i lettori successivi interpretare quali caratteri appartengono a quale parola). Storicamente alcune lingue antiche , in particolare FORTRAN (1955) e ALGOL (1958), consentivano spazi all'interno degli identificatori, determinando la fine degli identificatori in base al contesto. Questo è stato abbandonato nelle lingue successive a causa della difficoltà di tokenizzazione . È possibile scrivere nomi semplicemente concatenando le parole, e questo è talvolta usato, come mypackageper i nomi dei pacchetti Java, sebbene la leggibilità ne risenta per i termini più lunghi, quindi di solito viene utilizzata una forma di separazione.

Parole separate da delimitatori

Un approccio consiste nel delimitare parole separate con un carattere non alfanumerico . I due caratteri comunemente usati a questo scopo sono il trattino ("-") e il trattino basso ("_"); ad esempio, il nome di due parole " two words" sarebbe rappresentato come " two-words" o " two_words". Il trattino è usato da quasi tutti i programmatori che scrivono COBOL (1959), Forth (1970) e Lisp (1958); è anche comune in Unix per comandi e pacchetti ed è usato nei CSS . Questa convenzione non ha un nome standard, sebbene possa essere indicata come lisp-case o COBOL-CASE (confronta il caso Pascal ), kebab-case , brochette-case o altre varianti. Di questi, il caso kebab , risalente almeno al 2012, ha ottenuto da allora una certa valuta.

Al contrario, i linguaggi della tradizione FORTRAN/ALGOL, in particolare i linguaggi delle famiglie C e Pascal , usavano il trattino per l' operatore di sottrazione infisso e non volevano richiedere spazi attorno ad esso (come linguaggi a forma libera ), impedendone l'uso in identificatori. Un'alternativa è usare i caratteri di sottolineatura; questo è comune nella famiglia C (incluso Python), con parole minuscole, che si trova ad esempio in The C Programming Language (1978), ed è diventato noto come snake case . I caratteri di sottolineatura con maiuscolo, come in UPPER_CASE, sono comunemente usati per le macro del preprocessore C , quindi note come MACRO_CASE, e per le variabili di ambiente in Unix, come BASH_VERSION in bash . A volte questo viene chiamato scherzosamente SCREAMING_SNAKE_CASE.

Parole separate da lettere maiuscole

Un altro approccio consiste nell'indicare i confini delle parole usando la maiuscola mediale, chiamata " camelCase ", "caso Pascal", e molti altri nomi, rendendo così rispettivamente " two words" come " twoWords" o " TwoWords". Questa convenzione è comunemente usata in Pascal , Java , C# e Visual Basic . Il trattamento delle sigle negli identificatori (ad esempio " XML " e " HTTP " in XMLHttpRequest) varia. Alcuni impongono che siano minuscoli (es. XmlHttpRequest) per facilitare la digitazione, la leggibilità e la segmentazione , mentre altri li lasciano in maiuscolo (es XMLHTTPRequest) per la precisione.

Esempi di formati di identificatori di parole multiple

Metadati e convenzioni ibride

Alcune convenzioni di denominazione rappresentano regole o requisiti che vanno oltre i requisiti di uno specifico progetto o dominio del problema e riflettono invece un insieme più ampio di principi definiti dall'architettura software , dal linguaggio di programmazione sottostante o da altri tipi di metodologia interprogetto.

notazione ungherese

Forse la più nota è la notazione ungherese , che codifica lo scopo ("Apps Hungarian") o il tipo ("Systems Hungarian") di una variabile nel suo nome. Ad esempio, il prefisso "sz" per la variabile szName indica che la variabile è una stringa con terminazione null.

notazione posizionale

Uno stile utilizzato per caratteri molto brevi (otto caratteri o meno) potrebbe essere: LCCIIL01, dove LC sarebbe l'applicazione (Lettere di credito), C per COBOL, IIL per il particolare sottoinsieme del processo e 01 un numero di sequenza.

Questo tipo di convenzione è ancora in uso attivo nei mainframe dipendenti da JCL ed è presente anche nello stile MS-DOS 8.3 (massimo otto caratteri con separatore di punto seguito da un tipo di file di tre caratteri).

Schema di parole composte (OF Language)

"OF Language" di IBM è stato documentato in un manuale IMS ( Information Management System ).

Descriveva in dettaglio lo schema di parole PRIME-MODIFIER-CLASS, che consisteva in nomi come "CUST-ACT-NO" per indicare "numero di conto cliente".

Le parole PRIME avevano lo scopo di indicare le principali "entità" di interesse per un sistema.

Le parole MODIFIER sono state utilizzate per ulteriore perfezionamento, qualificazione e leggibilità.

Le parole CLASS idealmente sarebbero un elenco molto breve di tipi di dati rilevanti per una particolare applicazione. Le parole CLASS più comuni potrebbero essere: NO (numero), ID (identificatore), TXT (testo), AMT (importo), QTY (quantità), FL (flag), CD (codice), W (lavoro) e così via. In pratica, le parole CLASS disponibili sarebbero un elenco di meno di due dozzine di termini.

Le parole CLASS, tipicamente posizionate a destra (suffisso), servivano più o meno allo stesso scopo dei prefissi di notazione ungheresi .

Lo scopo delle parole CLASS, oltre alla consistenza, era quello di specificare al programmatore il tipo di dati di un particolare campo dati. Prima dell'accettazione dei campi BOOLEAN (solo due valori), FL (flag) indicava un campo con solo due valori possibili.

Convenzioni specifiche della lingua

ActionScript

Le convenzioni e best practice di codifica di Adobe suggeriscono standard di denominazione per ActionScript che sono per lo più coerenti con quelli di ECMAScript . Lo stile degli identificatori è simile a quello di Java .

Ada

In Ada , l'unico stile consigliato di identificatori è Mixed_Case_With_Underscores.

APL

Nei dialetti APL , il delta (Δ) è usato tra le parole, ad esempio PERFΔSQUARE (non esisteva tradizionalmente nelle versioni APL più vecchie). Se il nome utilizzava lettere sottolineate, al suo posto verrebbe utilizzata la barra inferiore delta (⍙).

C e C++

In C e C++ , le parole chiave e gli identificatori di libreria standard sono per lo più minuscoli. Nella libreria standard C , i nomi abbreviati sono i più comuni (ad es. isalnumper una funzione che verifica se un carattere è un numero), mentre la libreria standard C++ utilizza spesso un trattino basso come separatore di parole (ad es out_of_range. ). Gli identificatori che rappresentano le macro sono, per convenzione, scritti utilizzando solo lettere maiuscole e caratteri di sottolineatura (questo è correlato alla convenzione in molti linguaggi di programmazione di utilizzare identificatori tutti maiuscoli per le costanti). I nomi che contengono un doppio carattere di sottolineatura o che iniziano con un carattere di sottolineatura e una lettera maiuscola sono riservati per l'implementazione ( compilatore , libreria standard ) e non devono essere utilizzati (ad es. __reservedo _Reserved). Questo è superficialmente simile a stropping , ma la semantica differisce: i trattini bassi fanno parte del valore dell'identificatore, piuttosto che essere caratteri di virgolette (come è stropping): il valore di __foois __foo(che è riservato), not foo(ma in un diverso spazio dei nomi).

C#

Le convenzioni di denominazione C# in genere seguono le linee guida pubblicate da Microsoft per tutti i linguaggi .NET (vedere la sezione .NET di seguito), ma non vengono applicate convenzioni dal compilatore C#.

Le linee guida Microsoft raccomandano l'uso esclusivo solo di PascalCase e camelCase , con quest'ultimo utilizzato solo per i nomi dei parametri del metodo e i nomi delle variabili locali del metodo (inclusi i constvalori locali del metodo ). Un'eccezione speciale a PascalCase è fatta per gli acronimi di due lettere che iniziano un identificatore; in questi casi entrambe le lettere sono in maiuscolo (ad esempio IOStream); questo non è il caso per acronimi più lunghi (ad esempio, XmlStream). Le linee guida raccomandano inoltre che il nome dato a un interfacebe PascalCase preceduto dalla lettera I maiuscola , come in IEnumerable.

Le linee guida di Microsoft per la denominazione campi sono specifici per static, publice protectedcampi; i campi che non lo sono statice che hanno altri livelli di accessibilità (come internale private) non sono esplicitamente coperti dalle linee guida. La pratica più comune è usare PascalCase per i nomi di tutti i campi, ad eccezione di quelli che sono private(e né constné né static), a cui vengono dati nomi che utilizzano camelCase preceduti da un singolo carattere di sottolineatura; per esempio, _totalCount.

Qualsiasi nome identificativo può essere preceduto dal simbolo commerciale-at ( @ ), senza alcun cambiamento di significato. Cioè, entrambi factore si @factorriferiscono allo stesso oggetto. Per convenzione, questo prefisso viene utilizzato solo nei casi in cui l'identificatore sarebbe altrimenti una parola chiave riservata (come fore while), che non può essere utilizzata come identificatore senza il prefisso, o una parola chiave contestuale (come frome where), in cui casi il prefisso non è strettamente richiesto (almeno non al momento della sua dichiarazione; per esempio, sebbene la dichiarazione dynamic dynamic;sia valida, questo sarebbe tipicamente visto come dynamic @dynamic;per indicare immediatamente al lettore che quest'ultimo è un nome di variabile).

andare

In Go , la convenzione consiste nell'usare MixedCapso mixedCapspiuttosto che i caratteri di sottolineatura per scrivere nomi composti da più parole. Quando si fa riferimento a strutture o funzioni, la prima lettera specifica la visibilità per i pacchetti esterni. Rendere la prima lettera maiuscola esporta quel pezzo di codice, mentre il minuscolo lo rende utilizzabile solo nell'ambito corrente.

Giava

In Java , le convenzioni di denominazione per gli identificatori sono state stabilite e suggerite da varie comunità Java come Sun Microsystems, Netscape, AmbySoft, ecc. Di seguito sono elencati esempi di convenzioni di denominazione impostate da Sun Microsystems, dove un nome in " CamelCase " è composto di un numero di parole unite senza spazi, con l'iniziale di ciascuna parola - esclusa la prima parola - in maiuscolo - ad esempio "camelCase".

I compilatori Java non applicano queste regole, ma il mancato rispetto di esse può causare confusione e codice errato. Ad esempio, widget.expand()e Widget.expand()implicano comportamenti significativamente diversi: widget.expand()implica un'invocazione al metodo expand()in un'istanza denominata widget, mentre Widget.expand()implica un'invocazione al metodo statico expand()in class Widget.

Uno stile di codifica Java ampiamente utilizzato impone di utilizzare UpperCamelCase per le classi e LowerCamelCase per istanze e metodi . Riconoscendo questo utilizzo, alcuni IDE , come Eclipse , implementano scorciatoie basate su CamelCase. Ad esempio, nella funzione di assistenza al contenuto di Eclipse , digitare solo le lettere maiuscole di una parola CamelCase suggerirà qualsiasi nome di classe o metodo corrispondente (ad esempio, digitare "NPE" e attivare l'assistenza al contenuto potrebbe suggerire NullPointerException).

Le iniziali di tre o più lettere sono CamelCase anziché maiuscole (ad esempio, parseDbmXmlFromIPAddressinvece di parseDBMXMLFromIPAddress). Si può anche impostare il confine a due o più lettere (es parseDbmXmlFromIpAddress. ).

JavaScript

Le librerie JavaScript integrate utilizzano le stesse convenzioni di denominazione di Java. I tipi di dati e le funzioni di costruzione utilizzano maiuscole e minuscole ( RegExp , TypeError , XMLHttpRequest , DOMObject ) e i metodi utilizzano minuscole ( getElementById , getElementsByTagNameNS , createCDATASection ). Per essere coerenti, la maggior parte degli sviluppatori JavaScript segue queste convenzioni. Vedi anche: le convenzioni di Douglas Crockford

Lisp

La pratica comune nella maggior parte dei dialetti Lisp è usare i trattini per separare le parole negli identificatori, come in with-open-filee make-hash-table. I nomi delle variabili dinamiche iniziano e finiscono convenzionalmente con asterischi: *map-walls*. I nomi delle costanti sono contrassegnati da segni più: +map-size+.

.NETTO

Microsoft .NET consiglia UpperCamelCase , noto anche come PascalCase , per la maggior parte degli identificatori. ( LowerCamelCase è consigliato per parametri e variabili ) ed è una convenzione condivisa per i linguaggi .NET. Microsoft consiglia inoltre di non utilizzare alcun suggerimento per il prefisso del tipo (noto anche come notazione ungherese ). Invece di usare la notazione ungherese, si consiglia di terminare il nome con il nome della classe base; LoginButtoninvece di BtnLogin.

Obiettivo-C

Objective-C ha uno stile di codifica comune che ha le sue radici in Smalltalk .

Le entità di primo livello, incluse classi, protocolli, categorie e costrutti C utilizzati nei programmi Objective-C come variabili e funzioni globali, sono in UpperCamelCase con un breve prefisso tutto maiuscolo che indica lo spazio dei nomi, come NSString , UIAppDelegate , NSApp o CGRectMake . Le costanti possono facoltativamente essere precedute da una lettera minuscola "k" come kCFBooleanTrue .

Le variabili di istanza di un oggetto utilizzano LowerCamelCase preceduto da un carattere di sottolineatura, come _delegate e _tableView .

I nomi dei metodi utilizzano più parti LowerCamelCase separate da due punti che delimitano gli argomenti, ad esempio: application:didFinishLaunchingWithOptions: , stringWithFormat: e isRunning .

Pascal, Modula-2 e Oberon

I linguaggi Wirthiani Pascal, Modula-2 e Oberon generalmente usano Capitalizedo UpperCamelCaseidentificatori per programmi, moduli, costanti, tipi e procedure e/ lowercaseo lowerCamelCaseidentificatori per costanti matematiche, variabili, parametri formali e funzioni. Sebbene alcuni dialetti supportino il carattere di sottolineatura e il simbolo del dollaro negli identificatori, è più probabile che il caso snake e il caso macro siano limitati all'uso all'interno di interfacce API esterne.

Perla

Perl prende alcuni spunti dal suo patrimonio C per le convenzioni. Le variabili con ambito locale e i nomi delle subroutine sono in minuscolo con caratteri di sottolineatura infissi. Le subroutine e le variabili destinate a essere trattate come private sono precedute da un carattere di sottolineatura. Le variabili del pacchetto hanno il titolo in maiuscolo. Le costanti dichiarate sono tutte maiuscole. I nomi dei pacchetti sono maiuscole stricte mrominuscole tranne pragmata, ad esempio e , che sono minuscole.

PHP

Le raccomandazioni PHP sono contenute in PSR-1 ( PHP Standard Recommendation 1) e PSR-12. Secondo PSR-1, i nomi delle classi dovrebbero essere in PascalCase, le costanti di classe dovrebbero essere in MACRO_CASE e i nomi delle funzioni e dei metodi dovrebbero essere in camelCase.

Python e Ruby

Python e Ruby consigliano entrambi UpperCamelCaseper i nomi delle classi, CAPITALIZED_WITH_UNDERSCORESper le costanti e lowercase_separated_by_underscoresper altri nomi.

In Python, se un nome deve essere " privato ", è preceduto da uno o due caratteri di sottolineatura (in Python è più o meno un hack). Le variabili private vengono applicate in Python solo per convenzione. I nomi possono anche essere suffissi con un trattino basso per evitare conflitti con le parole chiave Python. Il prefisso con doppi caratteri di sottolineatura modifica il comportamento nelle classi per quanto riguarda la modifica dei nomi . Il prefisso e il suffisso con doppi caratteri di sottolineatura sono riservati ai "nomi magici" che soddisfano un comportamento speciale negli oggetti Python.

R

Sebbene non esista una guida di stile ufficiale per R , la guida di stile tidyverse di R-guru Hadley Wickham definisce lo standard per la maggior parte degli utenti. Questa guida consiglia di evitare caratteri speciali nei nomi dei file e di utilizzare solo numeri, lettere e trattini bassi per i nomi di variabili e funzioni, ad es. fit_models.R.

Raku

Raku segue più o meno le stesse convenzioni di Perl, tranne per il fatto che consente un trattino infisso - o un apostrofo ' (o virgolette) all'interno di un identificatore (ma non due di fila), a condizione che sia seguito da un carattere alfabetico. I programmatori Raku quindi usano spesso la custodia kebab nei loro identificatori; ad esempio, fish-foode don't-do-thatsono identificatori validi.

Ruggine

Rust consiglia UpperCamelCaseper alias di tipo e nomi di varianti di struct, trait, enum ed enum, SCREAMING_SNAKE_CASEper costanti o statici e snake_caseper nomi di membri di variabili, funzioni e struct.

Swift

Swift ha cambiato le sue convenzioni di denominazione con ogni singola versione. Tuttavia, un importante aggiornamento con Swift 3.0 ha stabilizzato le convenzioni di denominazione per le lowerCamelCasevariabili e le dichiarazioni di funzione trasversali. Le costanti sono generalmente definite da tipi enum o parametri costanti anch'essi scritti in questo modo. Le dichiarazioni di classe e altri tipi di oggetto sono UpperCamelCase.

A partire da Swift 3.0 sono state definite chiare linee guida di denominazione per il linguaggio nel tentativo di standardizzare le convenzioni di denominazione e dichiarazione delle API tra tutte le API di terze parti.

Guarda anche

• Categoria:Convenzioni di denominazione
• Stile di controllo
• Convenzioni di codifica
• Elenco degli strumenti per l'analisi del codice statico
• Spazio dei nomi
• Convenzione di denominazione
• Sigil (programmazione di computer)
• Sintassi (linguaggi di programmazione)

Riferimenti

link esterno

• coding-guidelines.com ha un pdf che utilizza la linguistica e la psicologia per tentare un'analisi costi/benefici dei problemi di denominazione degli identificatori