Introduzione a Visual Basic

Il linguaggio di programmazione Microsoft® Visual Basic® è un linguaggio di programmazione di alto livello per Microsoft .NET Framework. Anche se è progettato per essere un linguaggio avvicinabile e facile da imparare, è anche abbastanza potente per soddisfare le esigenze dei programmatori esperti. Il linguaggio di programmazione Visual Basic ha una sintassi simile all'inglese, che promuove la chiarezza e la leggibilità del codice Visual Basic. Se possibile, vengono usate parole o frasi significative anziché abbreviazioni, acronimi o caratteri speciali. La sintassi estranea o non necessaria è in genere consentita ma non necessaria.

Il linguaggio di programmazione Visual Basic può essere fortemente tipizzato o un linguaggio tipizzato in modo libero. La digitazione libera sfida gran parte del carico di controllo del tipo fino a quando un programma non è già in esecuzione. Ciò include non solo il controllo dei tipi delle conversioni, ma anche le chiamate al metodo, ovvero l'associazione di una chiamata al metodo può essere posticipata fino al runtime. Ciò è utile quando si creano prototipi o altri programmi in cui la velocità di sviluppo è più importante della velocità di esecuzione. Il linguaggio di programmazione di Visual Basic fornisce anche semantiche fortemente tipizzato che esegue tutto il controllo dei tipi in fase di compilazione e non consente l'associazione in fase di esecuzione delle chiamate al metodo. Ciò garantisce prestazioni massime e garantisce che le conversioni dei tipi siano corrette. Ciò è utile quando si creano applicazioni di produzione in cui la velocità di esecuzione e la correttezza dell'esecuzione sono importanti.

Questo documento descrive il linguaggio Visual Basic. Deve essere una descrizione del linguaggio completa anziché un'esercitazione linguistica o un manuale di riferimento di un utente.

Notazione grammaticale

Questa specifica descrive due grammatiche: una grammatica lessicale e una grammatica sintattica. La grammatica lessicale definisce il modo in cui i caratteri possono essere combinati per formare token; La grammatica sintattica definisce il modo in cui i token possono essere combinati per formare programmi Visual Basic. Esistono anche diverse grammatiche secondarie usate per le operazioni di pre-elaborazione, ad esempio la compilazione condizionale.

Le grammatiche in questa specifica sono scritte in formato ANTLR. Vedere http://www.antlr.org/.

Il caso non è importante nei programmi Visual Basic. Per semplicità, tutti i terminali verranno forniti in maiuscolo standard, ma qualsiasi combinazione di maiuscole e minuscole corrisponderà. I terminali stampabili del set di caratteri ASCII sono rappresentati dai corrispondenti caratteri ASCII. Visual Basic non fa inoltre distinzione tra la larghezza quando i terminali corrispondono ai terminali, consentendo ai caratteri Unicode a larghezza intera di corrispondere ai rispettivi equivalenti Unicode a metà larghezza, ma solo su base di token intero. Un token non corrisponde se contiene caratteri misti a metà larghezza e a larghezza intera.

Le interruzioni di riga e il rientro possono essere aggiunti per migliorare la leggibilità e non fanno parte dell'ambiente di produzione.

Compatibilità

Una funzionalità importante di un linguaggio di programmazione è la compatibilità tra versioni diverse del linguaggio. Se una versione più recente di un linguaggio non accetta lo stesso codice di una versione precedente del linguaggio o lo interpreta in modo diverso rispetto alla versione precedente, un onere può essere posto a un programmatore durante l'aggiornamento del codice da una versione del linguaggio a un altro. Di conseguenza, la compatibilità tra le versioni deve essere mantenuta tranne quando il vantaggio per i consumatori di linguaggio è di natura chiara e schiacciante.

I criteri seguenti regolano le modifiche apportate al linguaggio Visual Basic tra le versioni. Il termine linguaggio, se usato in questo contesto, si riferisce solo agli aspetti sintattici e semantici del linguaggio Visual Basic stesso e non include alcuna classe .NET Framework inclusa come parte dello Microsoft.VisualBasic spazio dei nomi (e sotto-spazi dei nomi). Tutte le classi in .NET Framework sono coperte da un criterio di compatibilità e controllo delle versioni separato all'esterno dell'ambito di questo documento.

Tipi di interruzioni di compatibilità

In un mondo ideale, la compatibilità sarebbe 100% tra la versione esistente di Visual Basic e tutte le versioni future di Visual Basic. Tuttavia, potrebbero esserci situazioni in cui la necessità di un'interruzione di compatibilità potrebbe superare il costo che può imporre ai programmatori. Tali situazioni sono:

• Nuovi avvisi. L'introduzione di un nuovo avviso non è, per se, un'interruzione di compatibilità. Tuttavia, poiché molti sviluppatori compilano con "considerano gli avvisi come errori" attivati, è necessario prestare particolare attenzione quando si introducono avvisi.

• Nuove parole chiave. L'introduzione di nuove parole chiave potrebbe essere necessaria quando si introducono nuove funzionalità del linguaggio. Verranno effettuati sforzi ragionevoli per scegliere parole chiave che riducono al minimo la possibilità di collisione con gli identificatori degli utenti e di usare parole chiave esistenti dove ha senso. La Guida verrà fornita per aggiornare i progetti dalle versioni precedenti ed eseguire l'escape di eventuali nuove parole chiave.

• Bug del compilatore. Quando il comportamento del compilatore è in contrasto con un comportamento documentato nella specifica del linguaggio, potrebbe essere necessario correggere il comportamento del compilatore in modo che corrisponda al comportamento documentato.

• Bug di specifica. Quando il compilatore è coerente con la specifica del linguaggio, ma la specifica del linguaggio è chiaramente errata, potrebbe essere necessario modificare la specifica del linguaggio e il comportamento del compilatore. La frase "chiaramente sbagliata" indica che il comportamento documentato viene eseguito contro ciò che una maggioranza chiara e ambigua degli utenti si aspetterebbe e produce un comportamento estremamente indesiderato per gli utenti.

• Ambiguità della specifica. Quando la specifica del linguaggio deve indicare ciò che accade in una determinata situazione, ma non lo fa e il compilatore gestisce la situazione in modo incoerente o chiaramente errato (usando la stessa definizione del punto precedente), può essere necessario chiarire la specifica e correggere il comportamento del compilatore. In altre parole, quando la specifica copre i casi a, b, d ed e, ma omette qualsiasi menzione di ciò che accade nel caso c e il compilatore si comporta in modo errato nel caso c, potrebbe essere necessario documentare ciò che accade nel caso c e modificare il comportamento del compilatore in modo che corrisponda. Si noti che se la specifica è ambigua per quanto accade in una situazione e il compilatore si comporta in modo non chiaramente errato, il comportamento del compilatore diventa la specifica di fatto.

• Errori di runtime in errori in fase di compilazione. In una situazione in cui il codice è 100% garantito un errore in fase di esecuzione (ad esempio, il codice utente ha un bug non ambiguo in esso), potrebbe essere consigliabile aggiungere un errore in fase di compilazione che intercetta la situazione.

• Omissione della specifica. Quando la specifica del linguaggio non consente o non consente una particolare situazione e il compilatore gestisce la situazione in modo indesiderato (se il comportamento del compilatore era chiaramente errato, sarebbe un bug di specifica, non un omissione della specifica), potrebbe essere necessario chiarire la specifica e modificare il comportamento del compilatore. Oltre all'analisi di impatto consueta, le modifiche di questo tipo sono ulteriormente limitate ai casi in cui l'impatto della modifica è considerato estremamente minimo e il vantaggio per gli sviluppatori è molto elevato.

• Nuove funzionalità. In generale, l'introduzione di nuove funzionalità non deve modificare le parti esistenti della specifica del linguaggio o il comportamento esistente del compilatore. Nella situazione in cui l'introduzione di una nuova funzionalità richiede la modifica della specifica del linguaggio esistente, tale interruzione di compatibilità è ragionevole solo se l'impatto sarebbe estremamente minimo e il vantaggio della funzionalità è elevato.

• Sicurezza. In situazioni straordinarie, i problemi di sicurezza possono richiedere un'interruzione di compatibilità, ad esempio la rimozione o la modifica di una funzionalità intrinsecamente non sicura e comporta un rischio chiaro per la sicurezza per gli utenti.

Le situazioni seguenti non sono accettabili per introdurre interruzioni di compatibilità:

• Comportamento indesiderato o deplorevole. La progettazione del linguaggio o il comportamento del compilatore che è ragionevole, ma considerato indesiderato o deplorevole, non è una giustificazione per interrompere la compatibilità con le versioni precedenti. Il processo di deprecazione del linguaggio, descritto di seguito, deve essere invece usato.

• Qualsiasi altra cosa. In caso contrario, il comportamento del compilatore rimane compatibile con le versioni precedenti.

Criteri di impatto

Quando si valuta se un'interruzione di compatibilità potrebbe essere accettabile, vengono usati diversi criteri per determinare l'impatto della modifica. Maggiore è l'impatto, maggiore è la barra per accettare le interruzioni di compatibilità.

I criteri sono:

• Qual è l'ambito della modifica? In altre parole, quanti programmi sono probabilmente interessati? Quanti utenti potrebbero essere interessati? Quanto è comune scrivere codice interessato dalla modifica?

• Esistono soluzioni alternative per ottenere lo stesso comportamento prima della modifica?

• Quanto è ovvio il cambiamento? Gli utenti riceveranno un feedback immediato che qualcosa è cambiato o i programmi verranno eseguiti in modo diverso?

• La modifica può essere ragionevolmente risolta durante l'aggiornamento? È possibile scrivere uno strumento in grado di trovare la situazione in cui si verifica la modifica con precisione perfetta e modificare il codice per aggirare la modifica?

• Qual è il feedback della community sulla modifica?

Deprecazione del linguaggio

Nel corso del tempo, parti del linguaggio o del compilatore possono diventare deprecate. Come illustrato in precedenza, non è accettabile interrompere la compatibilità per rimuovere tali funzionalità deprecate. È invece necessario seguire questa procedura:

1. Data una funzionalità presente nella versione A di Visual Studio, è necessario richiedere commenti e suggerimenti dalla community degli utenti in caso di deprecazione della funzionalità e avviso completo dato prima che venga presa qualsiasi decisione finale di deprecazione. Il processo di deprecazione può essere invertito o abbandonato in qualsiasi momento in base al feedback della community degli utenti.

2. la versione completa (ad esempio, non una versione punto) B di Visual Studio deve essere rilasciata con avvisi del compilatore che segnalano l'utilizzo deprecato. Gli avvisi devono essere attivati per impostazione predefinita e possono essere disattivati. Le deprecazioni devono essere chiaramente documentate nella documentazione del prodotto e sul Web.

3. È necessario rilasciare una versione C completa di Visual Studio con avvisi del compilatore che non possono essere disattivati.

4. Una versione completa D di Visual Studio deve essere successivamente rilasciata con gli avvisi deprecati del compilatore convertiti in errori del compilatore. Il rilascio di D deve verificarsi dopo la fine della fase di supporto Mainstream (5 anni a partire da questa scrittura) della versione A.

5. Infine, è possibile rilasciare una versione E di Visual Studio che rimuove gli errori del compilatore.

Le modifiche che non possono essere gestite all'interno di questo framework di deprecazione non saranno consentite.