Re: Umstieg von VB.NET auf C#

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance




"Christof Nordiek" <cn@xxxxxxxxx> schrieb im Newsbeitrag
news:OoHFLMjkHHA.1532@xxxxxxxxxxxxxxxxxxxxxxx
"Huber Peter" <buoi66@xxxxxxxx> schrieb im Newsbeitrag
news:802fe$463c58f3$54496963$32428@xxxxxxxxxxxxxxxxxx
Guten Tag

Ich habe schon mehrere Jahre Erfahrungen in VB.NET und muss jetzt
stellenbedingt auf C# umsteigen.
Dabei sind mir einpaar Dinge aufgefallen, und wollte mal fragen ob ihr
dies
auch so sieht, oder ob ich einfach noch was übersehen habe.

1. Man sagt oft in C# müsse man weniger Code eintippen, im Gegenteil im
VB.Net gebe ich "sub test" und Enter ein, die beiden Klammern und das End
sub erstellt mir die IDE auotmatisch. Im C# muss ich die geschweiften
Klammern, welche auf der Tastatur eher mühsam erreichbar sind selber
eintippen. Das selbe gilt z.B auch für IF.. else..

In VS2005 gibt es codesnippets auch für C#. Nicht für allgemeine Methoden,
aber z.B. für if, else, try/catch try/finally, do, while, Main-Methode mit
int und mit void als Rückgabe .... So weit ich weiß, kann man das auch
erweitern.

3. Einfache Funktionen wie zum Beispiel isdate() welche jedem VB.NET
Programmierer das leben sehr vereinfachen gibt es in C# nicht.
Objektorientierung hin oder her, aber wenn ich nur mal wissen will ob der
Benutzer eingültiges Datum eingegben hat, ist alles was komplizierter als
isdate() ist unnötig.

Wenn man die unbedingt nutzen will, kann man die auch in C# einbinden.
Einfach die Assembly Microsoft.VisualBasic referenzieren, und den
entsprechenden Namensraum einbinden.


4. Namensräume
Es ist nicht möglich die wichtigsten Namensräume eimal pro Projekt
anzugeben, nein man muss sie auf jeder Seite erneut angeben. Und zu allem
dazu muss man den Namensraum noch exact angeben.

Using System;
..
io.stream sr;

Geht nicht. In VB.NET wäre dies möglich und ich muss nicht extra den
Namensraum System.io angeben.

Mag auf dem ersten Blick wie ein Vorteil aussehen. Kann aber auch eher zu
Mehrdeutigkeiten führen. Insgesamt mach das aber nicht viel aus. Ist mehr
eine Gewohnheitssache.
In VS2005 lassen sich die using-Direktiven sowieso bei Bedarf einfach
nachtragen.

5. Case sensitive. Macht für mich keinen Sinn. Im Gegenteil, ich verwende
in
VB.NET immer Gross und Klein für Bezeichner, dann kann man das Objekt als
Kleinschreibung eingeben, und bei die IDE korrigiert es wären der
Eingabe,
wenn nicht habe ich mich vertippt.

Ist eine Gewohnheitssache. Ich komme mit case-sensitive besser zurecht.
Falscheingaben lassen sich auch in C# leicht korrigieren.

6. Vererbung. In C# ist es nicht sofort ersichtlich ob das Objekt nun von
einem andern Objekt erbt, oder ob es eine Schnittstelle implementiert.

Ist eigentlich kein Problem. Wenn überhaupt, ist nur der erste Typ in der
Liste eine Klasse. Wenn man sich an die Namenskonventionen hält, sind
Schnittstellen sowieso bereits am Namen zu erkennen.
Ich persönlich finde C# in diesem Punkt übersichtlicher.

Wenn
ich in VB.Net ein Schnittstelle implemenitere, erstellt mir die IDE eine
Vorlage mit allen zu implementierenden Funktionen und Sub'. In C# ist
handarbeit angesagt.

Ist in C# auch möglich. Zuminidest in VS2005. Da kann ich sogar
entscheiden ob die Schnittstellen implizit oder explizit implementiert
werden sollen.

7. Nun noch was zu einem der wenigen Vorteile. Refactoring, nettes und
praktisches Feature welches in VB.NET fehlt. Nur ich benutze das Refactor
Tool von Developer Express, dagegen ist das eingebaute C# Refactoring
eher
ein Spielzeug.

Wenn man die hat, OK. Aber das ist immerhin kein Nachteil von C#

Die Liste liesse sich nun noch beliebig erweitern. Umgekhert habe ich bis
heute aber noch kaum ein Vorteil von C# über VB.NET gefunden, der in der
Praxis auch wirklich von einer alltäglichen Relevanz ist. Mit der
Sprachsyntax habe ich eigentlich keine Probleme, ist halt einwenig ein
Umgewöhnen, aber das Framework ist schliesslich beidemale das selbe.

Ein frage hätte ich aber noch, wenn ich eine einfach property erstelle
sieht
die nach der automtaischen Formatierung immer so aus:
public Color TextBoxBackColor
{
get
{
return this.TextBox1.BackColor;
}
set
{
this.TextBox1.BackColor = value;
}
}

Das benötigt ja mehr Platz als bei VB.NET. Kann man der IDE bebringen das
sie es automatische etwa so formatiert:

public Color TextBoxBackColor {
get { return this.TextBox1.BackColor;}
set { this.TextBox1.BackColor = value; }
}

Guck mal unter Extras/Optionen und dann unter Text-Editor/C#/Formatierung,
da kannst du so einiges einstellen.

Christof

Der wichtigste Vorteil von C# ist die Eleganz der Notation und die
Vorgeschichte.
Hansueli





.



Relevant Pages

  • Re: Umstieg von VB.NET auf C#
    ... VB.Net gebe ich "sub test" und Enter ein, die beiden Klammern und das End ... sub erstellt mir die IDE auotmatisch. ... dazu muss man den Namensraum noch exact angeben. ... oder ob es eine Schnittstelle implementiert. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: SerialPort - Bei Ausschalten des Gerätes Programmabsturz
    ... Schnittstelle, auf welche Dein SerialPort-Objekt ... Private Sub Start_Load(ByVal sender As System.Object, ... Private Function AnyFunctionas Boolean ... Programm nach dem zehnten Polltimer-Tick, ...
    (microsoft.public.de.german.entwickler.dotnet.vb)
  • Re: Programablauf
    ... die Verarbeitung der Daten von der Schnittstelle ist nicht das Problem. ... Daten in Queue speichern ... Private Sub butStart_Click ... ' hier müste ja noch das auslesen und weiter verarbeiten der Daten ...
    (microsoft.public.de.german.entwickler.dotnet.vb)
  • Re: Programablauf
    ... Project mit Barcodescanner an der Seriellen Schnittstelle. ... Private BarCodeListe As System.Collections.Generic.Queue ... Private Sub butStart_Click ... ' serielle Schnittstelle schliesen, da durch wird auch der Tread der ...
    (microsoft.public.de.german.entwickler.dotnet.vb)
  • Re: Weird bug in VS.NET 2003 IDE
    ... > From time to time, when I save my code, the IDE decides to add lines to ... > End Sub ... > End Namespace ... > the IDE adding all these lines is that the program fails to compile, ...
    (microsoft.public.vsnet.ide)