Convertire la conoscenza di C # in VB.NET eventuali problemi potenziali?

Ho una squadra con persone che sono abbastanza a proprio agio in C # ma abbiamo avuto l’obbligo di scrivere un progetto in VB.net. Quanto sarebbe difficile pensare in C # e al volo convertire in VB? È fattibile?

Potresti elencare i problemi che possiamo incontrare?

Ho sentito che VB.net non ha chiusure. È ancora vero per .net 3.5?

Se ti stai avvicinando a VB.Net con la mentalità di C # è meglio impostare le seguenti opzioni nel progetto

  • Opzione rigorosa
  • Opzione esplicita
  • Opzione Inferiore

Ciò rimuove essenzialmente la semantica di binding tardiva di VB.Net e impone che sia un linguaggio tipizzato rigorosamente. Ciò lo renderà più vicino al C # semantico saggio (non ancora esatto in alcun modo).

VB.Net ha il supporto Lambda Expression (e quindi Closure) a partire dalla versione di Visual Studio 2008 / .Net Framework 3.5. Non espressione e non dichiarazione. Le dichiarazioni lambda non sono supportate fino a VS2010 / .Net Framework 4.0. Sebbene sia ansible utilizzare il compilatore 4.0 per downtarget 2.0 framework.

Siccome C # e VB.NET usano lo stesso framework e compilano codice IL molto simile, hai molto gratis. Scrivere la syntax di base invece non è così difficile.

La syntax C # è più finalizzata a mostrare cosa sta succedendo, mentre la syntax VB spesso nasconde alcuni dettagli, quindi un programmatore C # ha già familiarità con alcuni concetti che potrebbero non sembrare ovvi per un programmatore VB. In qualche modo imparare C # è un modo migliore per imparare come funziona VB piuttosto che imparare VB stesso …

Rispondo spesso alle domande di VB.NET in diversi forum basati principalmente sulla mia conoscenza di C # e non ho ancora scritto nulla di più dei brevi programmi di test in VB.NET.

Ovviamente ci sono alcune stranezze da cercare in VB. Come l’operatore /, ad esempio, converte sempre entrambi gli operandi in double, oppure l’operando = che utilizza il codice di confronto specifico VB piuttosto che il confronto specificato per l’operatore di uguaglianza nelle classi .NET.

Un’area che VB.NET tende a provare e coprire è lavorare con gli eventi; altri hanno brevemente toccato alcune delle differenze, ma qui c’è un po ‘di più su di loro:

VB.NET fornisce una parola chiave WithEvents per i campi che generano eventi. Se il campo è dichiarato WithEvents è ansible aggiungere un campo Handles field.Event alla fine di un metodo la cui firma è compatibile con l’evento; quel metodo sarà automaticamente un delegato dell’evento senza bisogno di RemoveHandler manualmente AddHandler e RemoveHandler ( += e -= ).

 Private WithEvents SomeField Public Sub SomeField_SomeEvent(sender as Object, e as EventArgs) Handles SomeField.SomeEvent Console.Writeline("SomeEvent occured") End Sub 

Le dichiarazioni degli eventi e gli eventi di innalzamento sono semplificati un po ‘. VB.NET non richiede di controllare se un evento è nullo prima di avvisare gli ascoltatori:

 Public event SomeEvent as EventHandler(of SomeEventArg) Public Sub SomeMethod() RaiseEvent SomeEvent(Me, new EventArgs) End Sub 

Una caratteristica “nascosta” degli eventi in VB.NET è l’accesso al MulticastDelegate sottostante, per fare qualcosa come GetInvocationList() Nota: l’evento si chiama SomeEvent e il codice per accedere a multicastdelegate chiama un campo invisibile chiamato SomeEventEvent :

 Public event SomeEvent as EventHandler(of SomeEventArg) Public Sub SomeMethod() // Note that SomeEvent's MulticastDelegate is accessed by appending // another "Event" to the end, this sample is redundant but accurate. // If the event was named ListChanged then it would be ListChangedEvent dim invocationList = SomeEventEvent.GetInvocationList() End Sub 

Uno dei maggiori problemi che ho riscontrato è l’apparente verbosità di VB. Ha tutte queste grandi parole chiave come MustInherit , NotInheritable , MustOverride , ecc., Dove C # ha solo cose come sealed , abstract e virtual . Devi avere un End to everything ( End Sub , End Function , End While , End Namespace , End Class , ecc.) E devi contrassegnare esplicitamente le proprietà di sola lettura con la parola chiave ReadOnly ; semplicemente omettendo il setter non volerà. Ricordando anche AndAlso e OrElse invece del più intuitivo (ma non cortocircuito) And e Or , e cose come Is Nothing e IsNot Nothing invece di == null o != null .

Nessuno di questi è necessariamente un problema con la lingua, ma se sei abituato alla relativa semplicità di C #, il codice VB potrebbe sembrare un sacco di cose extra per te.

C’erano alcuni articoli utili nella rivista Visual Studio nel gennaio 2008.

  • Quali sviluppatori di C # dovrebbero sapere su VB
  • E per completezza, quali sviluppatori VB dovrebbero sapere su C #

Potresti anche essere interessato alla domanda ” cosa è permesso in VB che è vietato in C # (o viceversa) ”

Un punto che non è stato menzionato qui è che gli inizializzatori di campo in C # vengono eseguiti prima del costruttore base, mentre quelli in VB funzionano tra il costruttore base e la prima istruzione “reale” del costruttore class derivata (dopo la chiamata costruttore base , se del caso). Ciò consente agli inizializzatori di campo in una class derivata di utilizzare i membri della class base (che potrebbero essere stati inizializzati usando i parametri passati al costruttore), ma significa anche che se il costruttore della class base di un object si passa da qualche parte prima ritorna, l’object parzialmente costruito può essere utilizzato prima dell’esecuzione di tutti gli inizializzatori di campo. In C #, tutti gli inizializzatori di campo verranno eseguiti prima che il costruttore base inizi l’esecuzione, ma nessuno degli inizializzatori di campo sarà in grado di utilizzare l’object parzialmente costruito.

PS: se qualcuno delle persone Microsoft dietro C # lo leggesse, ci sarebbe una particolare difficoltà nell’aggiungere una parola chiave sensibile al contesto per le dichiarazioni di campo per specificare se devono essere elaborate prima o dopo il costruttore di base, o eventualmente farle eseguire da alcuni metodo speciale che potrebbe essere chiamato dal costruttore, che potrebbe essere racchiuso in un blocco try-finally (quindi eventuali IDisposables così allocati potrebbero essere ripuliti) e potrebbe anche essere in grado di utilizzare i parametri passati al costruttore?

Trovo che questo sia un utile articolo per evidenziare le differenze. Sono un programmatore di vb.net, e questo mi aiuta a capire il codice c #, quindi sono sicuro che funzionerà dall’altra parte!

http://www.codeproject.com/KB/dotnet/vbnet_c__difference.aspx

Proprio come qualsiasi altra lingua (umana o informatica), per prima cosa impari a “tradurre nella tua testa”, poi alla fine inizi a “pensare” nell’altra lingua.

Quanto più velocemente la tua squadra può fare quel salto, tanto meglio. Quindi, fallo allo stesso modo in cui gli esperti ti dicono di imparare una lingua umana: esempi del mondo reale e immersione.

Sono disponibili online alcune utilità di conversione da C # a VB.NET, quindi iniziare facendo scrivere al team in C #, convertire in VB.NET e pulirlo. (Le utilità di conversione variano in termini di qualità e presentano alcune limitazioni, in particolare con le nuove funzionalità linguistiche.)

Una volta che hanno appreso la “grammatica” di base, inseriscili in VB.NET al 100%.

Uso entrambi tutti i giorni, spesso in windows di codice diverse allo stesso tempo, e non ho problemi a cambiare contesto o a fare la “cosa giusta” in ciascuna.

A parte ciò che Jared ha già menzionato, non dovresti avere problemi a farlo. L’unica altra fonte di irritazione sono le insolite impostazioni predefinite. EG Lo sapevi che i progetti VB.NET nascondono per impostazione predefinita il nodo di riferimento in solution explorer? (devi selezionare ShowAllFiles per vederlo).

Penso che C # per VB.NET non sarà troppo doloroso, è solo un caso di imparare una nuova syntax. Nelle versioni attuali le capacità di entrambe le lingue sono abbastanza allineate.

Il contrario (da VB.NET a C #) potrebbe essere più difficile perché le persone potrebbero essere utilizzate per utilizzare il namespace “My” e altre cose messe lì per far sentire gli sviluppatori di VB6 a casa.

Ci sono alcune sottili differenze a cui dovrai fare attenzione. Ad esempio VB.Net non ha alcun concetto di cortocircuito su un’istruzione if (sono stato corretto che apparentemente lo fa). Se si tratta solo di un progetto a breve termine, probabilmente non avrai problemi, ma linguaggi diversi hanno approcci diversi per risolvere lo stesso problema. Un esempio di questo sono i programmatori Python che parlano di fare cose nel modo “pythonic”. Parlano di questo concetto nel libro Dreaming in Code, in cui i programmatori java stavano cercando di programmare java usando la syntax python. Porta a prendere la strada lunga per risolvere un problema. Succederà con C # e VB.Net? È difficile da dire, entrambi usano il lavoro del frame sottostante, quindi le differenze non saranno enormi, ma sarebbe comunque utile per provare e imparare come usare VB.NET nel modo in cui era previsto.

Modifica: così apparentemente, ha il concetto di cortocircuito, ma non lo fa di default dove C # lo fa. Ciò dimostra ulteriormente il punto di apprendere come le funzioni linguistiche possano essere utili a lungo termine.

Non penso che sarebbe troppo difficile. VB.NET e C # sono lingue vicine l’una all’altra, solo la syntax differisce davvero. Ovviamente ci vorrà del tempo perché la tua squadra si abitui alla nuova lingua, ma non credo che ti imbatterai in grossi problemi.

Oh, e VB.NET ha chiusure. Mancano alcune altre funzionalità di C # come la parola chiave yield, i lambda multi-statement e le proprietà auto, ma nulla di molto critico.

Un’opzione se non hai voglia di scrivere il codice vb.net è scrivere il tuo progetto in C #, compilarlo e usare Reflector per vedere come appare l’equivalente di vb.net. In ogni caso, tutto si riduce a MSIL!