Non ho visto nessuno commentare la tua seconda domanda esplicita alla fine: "2: è abbastanza convincente per me da considerare di passare a C # se il caso VB.NET sta in qualche modo limitando ciò che potrei fare con il codice?"
Preferisco l'approccio con più opzioni che C # consente al programmatore di scegliere se limitare le opzioni del programmatore. Preferisco di gran lunga C #, ma per la sola distinzione tra maiuscole e minuscole, non lo penserei nemmeno vicino all'apprendimento di una lingua solo perché è sensibile al maiuscolo / minuscolo. tutte le caratteristiche sono ciò che conta, e quando guardo i vantaggi di entrambi, C # e VB.NET, preferisco fortemente C #. ma ti darò una vera prospettiva equilibrata, di parte sì, perché ho una preferenza, ma sarò onesto anche sugli svantaggi del C #.
prima di tutto, entrambe le lingue presentano vantaggi e svantaggi. le differenze che puoi fare in una lingua che non possono essere fatte nell'altra stanno diminuendo poiché, per fortuna, Microsoft sta migliorando entrambe le lingue e sembrano non mostrare una parzialità ingiusta verso nessuna delle due lingue.
quando C # è uscito per la prima volta, VB non aveva i suoi commenti XML che potresti mettere prima dei metodi, cosa che ho amato in C #. Lo odiavo in VB.NET. ma negli anni ho visto che molte funzionalità che non sono in una lingua vengono aggiunte all'altra. (lo stesso team di sviluppatori MS sviluppa sia C # che VB, quindi ha senso che le funzionalità diventino abbastanza simili.)
ma hai chiesto cosa ha C # che VB non ha. eccone alcuni a cui posso pensare immediatamente:
1: C # è più conciso e richiede meno battitura .. in MOLTI modi! Ho persino visto la stupidità parlare quando viene fatta l'affermazione opposta, che VB salva la digitazione. ma per favore ascolta le persone che ti dicono che usano entrambe le lingue, e nessuna delle due è usata raramente da loro. io uso entrambi C # cheVB, C # a casa perché mi piace (e quando lavoro con C # al lavoro), e le mie richieste di lavoro più recenti che uso VB e non C #. quindi sto utilizzando più frequentemente VB ora (da circa 10 mesi), ma nella mia testimonianza personale, preferisco di gran lunga C #, e in termini di battitura effettiva, VB è notevolmente più digitazione. l'unico esempio che ho letto in cui qualcuno ha effettivamente provato a dire che VB era più conciso, stava dando un esempio "with ..." con una variabile lunga nel con, quindi in VB, potresti semplicemente usare ".property". questa è stupidità nell'affermare che VB ha bisogno di meno battitura. ci sono alcune cose (e non solo questo esempio) in cui VB è più breve, ma molte più volte quando C # è più conciso, nella pratica reale.
ma il motivo principale per cui credo che C # sia più conciso, sono le verbose dichiarazioni "IF / THEN" di VB. le istruzioni if sono comuni. in C # non c'è nessuna parola "allora" da digitare! :) anche tutte le istruzioni 'end ...' richiedono la digitazione che, in c #, di solito è solo una parentesi graffa di chiusura '}'. Ho letto che alcune persone affermano che questa maggiore verbosità in VB.NET è un vantaggio per VB poiché diverse istruzioni / simboli di blocco di chiusura possono essere annidati e terminare immediatamente l'uno accanto all'altro, ma non sono abbastanza d'accordo. una persona può quasi sempre scrivere un programma meglio in C # o VB rispetto a un altro programmatore perché la prossima revisione del codice potrebbe essere progettata meglio. questo vale per la "confusione di numerose parentesi graffe di chiusura in C #" e se i blocchi annidati sono tutti dello stesso tipo come diversi IF annidati, VB soffre dello stesso problema che ha in C #. questo non è un vantaggio in VB. questa situazione è precisamente il motivo per cui mi piace commentare il significato del mio simbolo di chiusura o dichiarazione di chiusura in entrambe le lingue. sì, questo è più prolisso da fare, ma in entrambe le lingue hai la possibilità di essere chiaro, il che è importante nei casi specifici basati sul giudizio e sulla situazione. Penso che la chiarezza del codice sia abbastanza importante.
2: VB non ha commenti su più righe. quando ho lavorato con VB non mi importava. poi sono passato ad alcuni linguaggi in stile C. ora sono tornato principalmente a utilizzare VB.NET al lavoro e mi mancano. è solo qualcosa che trovi conveniente e che poi devi perdere. :(
3: "andalso" e "orelse" di VB è piuttosto fastidioso da digitare tutto questo quando in C # sono semplicemente "&&" e "||". ancora una volta, meno battitura. questo non è raro nel mio codice sia in VB che in C #. semmai, per la funzionalità, 'OR' vs 'OrElse' di solito non ha importanza tranne che 'OrElse' è più veloce per il computer, quindi se un programmatore usa solo 'Or' e 'And' in VB, allora produce un codice meno ottimale per qualcuno a cui piace la chiarezza del codice. "Or" è molto più facile da scorrere rispetto a "OrElse".
4: maggiore flessibilità nel posizionamento del codice in C #. quando una riga è lunga e si desidera avvolgerla nella riga successiva, odio il riadattamento del mio codice da parte di VB.NET. C # lo fa un po ', ma lo trovo più utile in C #, dove in VB, è molto più controllo. ma questo è più dell'IDE VB.NET rispetto all'IDE C # piuttosto che il linguaggio stesso. ma non so se vuoi entrambe o puramente le funzionalità del linguaggio senza differenze IDE.
5: quello che mi manca davvero è solo creare un nuovo blocco di codice in C #, potrei avere molte cose accadute in un metodo e voglio dichiarare una variabile in un blocco di codice molto piccolo ma non avere quella variabile dichiarata al di fuori di quel blocco in l'intero metodo. in C #, possiamo semplicemente creare un nuovo blocco con "{" e terminarlo con "}". VB non ha questa caratteristica, ma la sua corrispondenza più simile è un blocco incondizionato "If True Then" e "End If". (nota l'equivalente di 2 caratteri C # vs 18 caratteri VB.NET di nuovo ... più digitando VB.)
6: incremento sé e gli operatori di decremento: ++ e - come nei myVariable++o ++myVariableo versioni decremento equivalenti. questo è molto utile ... a volte. ecco un esempio di codice effettivo quando ho perso molto C #:
// C#:
while (txt.Length > x)
{
thisChar = txt[x];
if (charsAllowedWithoutLimit.Contains(thisChar)) { ++x; }
else if (allowLettersWithoutLimit && char.IsLetter(thisChar)) { ++x; }
else if ((x2 = charsAllowedWithLimit.IndexOf(thisChar)) >= 0)
{
++x; if (++usedCountA[x2] > charAllowedLimit[x2]) { break; }
}
else { break; }
}
' VB.NET:
While (txt.Length > x)
thisChar = txt(x)
If (charsAllowedWithoutLimit.Contains(thisChar)) Then
x += 1
ElseIf (allowLettersWithoutLimit AndAlso Char.IsLetter(thisChar)) Then
x += 1
Else
x2 = charsAllowedWithLimit.IndexOf(thisChar)
If (x2 >= 0) Then
x += 1
usedCountA(x2) += 1S
If usedCountA(x2) > charAllowedLimit(x2) Then Exit While
Else
Exit While
End If
End If
End While
E solo per dare un MOLTO buon esempio in cui le regole C #, questo è più codice che ho scritto personalmente di recente:
// C#
public static bool IsNotWithin(this Byte v, Byte v1, Byte v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this SByte v, SByte v1, SByte v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int16 v, Int16 v1, Int16 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int32 v, Int32 v1, Int32 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Int64 v, Int64 v1, Int64 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsNotWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 > v && v < v2) || (v2 < v && v > v1); }
public static bool IsWithin(this Byte v, Byte v1, Byte v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this SByte v, SByte v1, SByte v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int16 v, Int16 v1, Int16 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int32 v, Int32 v1, Int32 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Int64 v, Int64 v1, Int64 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt16 v, UInt16 v1, UInt16 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt32 v, UInt32 v1, UInt32 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this UInt64 v, UInt64 v1, UInt64 v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
public static bool IsWithin(this Decimal v, Decimal v1, Decimal v2) { return (v1 <= v && v <= v2) || (v2 <= v && v <= v1); }
' And the VB equivalent is a mess! Here goes:
<Extension()>
Public Function IsNotWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsNotWithin(v%, value1%, value2%) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsNotWithin(v&, value1&, value2&) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsNotWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsNotWithin(v@, value1@, value2@) As Boolean
Return (value1 > v AndAlso v < value2) OrElse (value2 < v AndAlso v > value1)
End Function
<Extension()>
Public Function IsWithin(v As Byte, value1 As Byte, value2 As Byte) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As SByte, value1 As SByte, value2 As SByte) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As Int16, value1 As Int16, value2 As Int16) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
' the % suffix means 'As Integer' in VB.
<Extension()>
Public Function IsWithin(v%, value1%, value2%) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
' the & suffix means 'As Long' in VB.
<Extension()>
Public Function IsWithin(v&, value1&, value2&) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As UInt16, value1 As UInt16, value2 As UInt16) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As UInt32, value1 As UInt32, value2 As UInt32) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
<Extension()>
Public Function IsWithin(v As UInt64, value1 As UInt64, value2 As UInt64) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
' the @ suffix means 'As Decimal' in VB.
<Extension()>
Public Function IsWithin(v@, value1@, value2@) As Boolean
Return (value1 <= v AndAlso v <= value2) OrElse (value2 <= v AndAlso v <= value1)
End Function
Forse questa è una prova enuf che C # è più conciso. Ma non tutti i programmatori amano la concisione. Alcuni preferiscono leggere "se a <b allora ..." perché è più naturale per il loro linguaggio umano. E va benissimo. Le preferenze vanno bene. Per me, lo sforzo con la mano è un fattore che apprezzo, e penso che chiunque possa abituarsi a pensare in qualsiasi simbolo preferisca, perché "se" e "allora" sono simboli di un alfabeto, e l '"istruzione if (condizione) di C #;" anche la sintassi sono simboli. uno è solo più vicino alla sintassi dei non programmatori rispetto agli altri. preferisco quello conciso.
Penso anche che dover usare "c" dopo i caratteri letterali in VB per renderlo un carattere letterale piuttosto che una stringa sia fastidioso. Mi piace molto di più la concisione di C # con questo. quando un metodo richiede un carattere letterale, è necessario fornire un carattere non una stringa con una lunghezza di un carattere, quindi a volte sei costretto a usarlo ":"cin VB mentre in C # lo è ':'. Penso che questo sia pignolo comunque.
Per essere onesti, devo dire ci sono vantaggi mi piace VB come non dover mettere parentesi vuote dopo le chiamate di metodo, come Dim nameUpper$ = name.ToUpperInvariantdove C # richiede le parentesi vuote: string nameUpper = name.ToUpperInvariant(). o il doppio che, come il taglio è troppo: Dim nameUpper$ = name.Trim.ToUpperInvariantvs string nameUpper = name.Trim().ToUpperInvariant(). Mi piace l'uso conciso di VB di come ho appena usato$ sopra per attenuarlo 'As String' dove C # non ha quelle scorciatoie. VB ha quelle scorciatoie per i tipi String, Integer, Long, Decimal, Single e Double, ma lo svantaggio è che è meno chiaro, quindi lo uso con cautela. ma comunque, preferisco il codice conciso.
Bene, questi sono solo alcuni suggerimenti di questo programmatore esperto e, come considero, questa è la mia "testimonianza" di programmazione di C # vs VB. entrambe sono belle lingue comunque, secondo me. ma sì, preferisco ancora di gran lunga C #.
ps Dato che ho intenzione di programmare per la maggior parte della mia vita, ho persino reimparato a digitare utilizzando la tastiera più efficiente: la tastiera Dvorak, che impiega circa 1/3 dello sforzo per digitare l'inglese rispetto a una tastiera Qwerty. cercalo. forse potresti voler cambiare anche tu. ;) ha reso la mia digitazione più facile del 67%! :) Incoraggio chiunque a pensare fuori dagli schemi e valutare una migliore efficienza nel proprio lavoro. Il layout di tastiera semplificato Dvorak e C # lo hanno fatto per me. :)
PSS confronterei Dvorak e C # con la metrica rispetto al layout della tastiera Qwerty e VB alle misurazioni empiriali. Dvorak, metric e C # sono semplicemente "puliti". MA VB non è molto indietro. Ma soffre della necessità di essere retrocompatibile con il vecchio codice VB6 e il codice pre .NET, come "Or" vs "OrElse" e "IIF ()".
Concludo con una cautela. Si prega di essere più prudenti che ascoltare persone che non sanno veramente di cosa stanno parlando. La metà di tutti gli svantaggi contro VB e C # lo sono non lonessun problema più, e le persone continuano a postare su di loro ignorando quali svantaggi esistono ancora nella lingua. Il miglior esempio a cui riesco a pensare sono i commenti XML per i metodi che utilizzano il triplo apostrofo in VB o simboli di commento a tripla barra in C #. Ma per favore discernere da soli se una persona parla per ignoranza o per esperienza. La testimonianza personale significa che sanno dalla loro esperienza reale. E dopo che qualcuno ha molta esperienza, rianima le orecchie. Ho più di 10 anni di esperienza sia in C # che in VB. E si riduce a questo: entrambe sono (molto) buone lingue. E la maggior parte delle differenze, puoi vedere immediatamente entro 5 minuti dalla lettura del codice. Ma sì, altre caratteristiche possono richiedere anni per trovare un handicap. E un handicap di cui sono a conoscenza (in C #), posso ' Non pensare nemmeno a una situazione di vita reale in cui sarebbe utile. Quindi forse non è un handicap, dopotutto.
Buona programmazione!