Laden...

VB.NET Einschränkung gegenüber C#

Erstellt von camelord vor 15 Jahren Letzter Beitrag vor 15 Jahren 3.196 Views
camelord Themenstarter:in
256 Beiträge seit 2006
vor 15 Jahren
VB.NET Einschränkung gegenüber C#

Hallo,

da ich seit drei Jahren mit C# programmiere würde ich auch gerne dabei bleiben.
Nun gibt es in unserer Firma jedoch bald ein zweijähriges Projekt, dass in VB.NET kodiert werden muss. Dies ist eine Vorgabe vom Kunden.

Kann mir jemand eine Einschränkung von VB.NET im vergleich zu C# nennen, sodass ich eine gute Argumentationsgrundlage habe, doch C# zu verwenden.

Gruß
camelord

365 Beiträge seit 2007
vor 15 Jahren

Soweit Ich weiß gibt es doch Konvertierer von VB.Net zu C# und andersherum....
Schliesst das nicht ein, das beide Sprachen dieselben Einschränkungen haben?!
Die Syntax ist anders und vielleicht paar Features, jedoch denke Ich da beides Net - Sprachen sind werden diese sowieso vorher in IL - Code kompiliert.

Steinigt mich wenn Ich falsch liege 😁 X(

Einen kleinen Artikel findest du HIER

Zitat aus der Quelle:

Fazit: Egal ob C# oder VB.NET – beide Sprachen können bis auf wenige Details das Selbe, was sich aber mit VB.NET 2005 (Erscheinungstermin: voraussichtlich 3. Quartal 2005) ändern wird. Auch bringt das Umschreiben von Code in eine andere Sprache keinen Sinn, besser ist es, einfach eine neue Klasse zu erstellen, die den vorhandenen Code überschreibt.

4.506 Beiträge seit 2004
vor 15 Jahren

Hallo camelord,

meine folgenden Aussagen beziehen sich auf .NET 2.0! (VB für .NET 3.5 habe ich mir noch nicht anschauen können)

gegenüber dem Kunden wirst Du so keine Argumente technischer Art durchsetzen können. Außer Argumenten wie z.B. "wenn wir das mit VB.NET machen müsen, wird es länger dauern" wirst Du nichts vorbringen können.

Technisch gesehen bietet C# und VB.NET kaum Unterschiede. Ein gravierender Mangel an VB.NET ist das Fehlen von anonymen Methoden (siehe auch hier: [gelöst] VB.NET Threadsichere Eigenschaften)

Ansonsten sind es größtenteils nur syntaktische Unterschiede, die z.B. hier aufgeführt werden:
Microsoft Whitepaper - Differences between C# and VB.NET

Viele Grüße
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

Q
214 Beiträge seit 2006
vor 15 Jahren

Hallo,
als Argumentation könntest du verwenden, dass du den Codestile von C# deutlich angenehmer findest und somit produktiver arbeiten kannst, da dir C# Code deutlich aufgeräumter und übersichtlicher vorkommt.

Ansonsten fallen mir spontan keine nennenswerten Einschränkungen von VB.Net ein, und wenn es der Kunde fordert, musst du dem auch nachkommen.

Ansonsten:
http://en.wikipedia.org/wiki/Comparison_of_C_sharp_and_Visual_Basic_.NET

365 Beiträge seit 2007
vor 15 Jahren

Finde das Argument mit der Übersichtlichkeit ziemlich kräftig...

Hallo,
als Argumentation könntest du verwenden, dass du den Codestile von C# deutlich angenehmer findest und somit produktiver arbeiten kannst, da dir C# Code deutlich aufgeräumter und übersichtlicher vorkommt.

Wenn Ich mir einen VB - Code anschaue läuft mir ein kalter Schauer den Rücken hinunter 😁
Und nach 3 Jahren C# siehts du vieles auf einen Blick, wo du dich in VB Ellen lang einarbeiten müsstest.
Hat VB.Net eigentlich die XML - Kommentarfunktion wie C#?!

Gelöschter Account
vor 15 Jahren

es gibt unterschiede von vb zu c#, die inkompatibel sind. welche, kann dir peter buchner oder jemand anders genauer nennen. die unterschiede halten sich jedoch meines wissens in grenzen, da ja so oder so beide sprachen in IL übersetzt werden und spätestens da haben die einen gemeinsamen nenner. das einzige problem ist nur das die sprache selbst ein paar einschränkungen hat.

das wohl effizienteste argument, das du in diesem fall bringen kannst ist geld.
es kostet einfach wesentlich mehr, wenn du mit einer sprache nciht vertraut bist, auch wenn die basis die selbe ist.

das zweite argument ist, das wenn sie vb-entwickler haben, die den code auch sehen wollen, das sie genausogut auch den reflector nehemn können und die anzeigesprache auf vb stellen können. der rest ist immer das selbe und design etc wird so oder so nicht mit quellcode dokumentiert.
nur wenn sie direkt im code hantieren wollen siht es für dich wiederrum schlecht aus.

edit: .. ich bin irgendwie viel zu langsam...

camelord Themenstarter:in
256 Beiträge seit 2006
vor 15 Jahren

Gut, ich denke sobald man nur "Geld" ausspricht wird jeder hellhörig.
Das wird das beste Argument sein. Alles andere (z.B. Übersichtlichkeit des Codes) interessiert einen Kunden nicht. Sowas finde nur ich als Entwickler interessant.

Vielen Dank für die vielen Antworten!

Gruß
camelord

M
205 Beiträge seit 2008
vor 15 Jahren

Hat VB.Net eigentlich die XML - Kommentarfunktion wie C#?!

ja, mit '''

mfg Markus

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo camelord,

Nun gibt es in unserer Firma jedoch bald ein zweijähriges Projekt, dass in VB.NET kodiert werden muss. Dies ist eine Vorgabe vom Kunden.

wenn der Kunde die Vorgabe macht, weil die Anwendung anschließend von seinen VB.NET Programmierern gepflegt werden soll, hast du wohl keine Chance.

Wenn der Kunde VB.NET will, weil er denkt, dass man damit Effizienter als mit C# iist, dann kannst du das Argument leicht umdrehen.

Es hängt also von den Gründen des Kunden ab. Sind dir diese bekannt?

herbivore

4.939 Beiträge seit 2008
vor 15 Jahren

Dann erstell doch einfach dein Programm in C# und wenn der Kunde es auch haben will, dann nimm ein "C# to VB.NET" Konvertierungstool (alternativ mit dem .NET Reflector).

Gelöschter Account
vor 15 Jahren

@Th69

das problem ist, das auch der reflector nicht zu 100% funktioniert. so ist der code, den er produziert oft nciht ohne weiteres kompilierbar. auch ein konvertierungstool geht nicht zu 100%. bei diesen tools geht es in erster linie darum den rahmen zu schaffen, damit man so wenig wie möglich selber hand anlegen muss und beim reflector geht es eigendlich nur darum, zu sehen was eigendlich passiert. da ist das kompilierbare darstellen des ursprünglichen quellcodes nur sekundäres ziel.

J
1.114 Beiträge seit 2007
vor 15 Jahren

Eine Einschränkung hat das Ganze... VB.NET ist nicht case-sensitive, d.h. eine Methode TEST() und test() können nicht unterschieden werden. Beim Erstellen von VB.NET Code mag das irrelevant sein, versuchst du jedoch eine Assembly einzubinden, die in C# kompiliert wurde und eben genau diese beiden Test() Methoden mitbringt, so kannst du diese nicht in VB.NET aufrufen (keine von beiden).

J
57 Beiträge seit 2008
vor 15 Jahren

Eine Einschränkung hat das Ganze... VB.NET ist nicht case-sensitive, d.h. eine Methode TEST() und test() können nicht unterschieden werden. Beim Erstellen von VB.NET Code mag das irrelevant sein, versuchst du jedoch eine Assembly einzubinden, die in C# kompiliert wurde und eben genau diese beiden Test() Methoden mitbringt, so kannst du diese nicht in VB.NET aufrufen (keine von beiden).

Wer sowas tut, sollte sich sowieso einen neuen Beruf suchen.

PS:
Case-insensitivity ist eh viel besser. 🙂

4.506 Beiträge seit 2004
vor 15 Jahren

Hallo Jabe,

Wer sowas tut, sollte sich sowieso einen neuen Beruf suchen.

Naja, das ist schon hart formuliert. Ich würde eher sagen, dass derjenige an seiner Egozentriertheit (gibts das Wort so überhaupt 🤔 ) arbeiten sollte.

Das Problem ist wahrscheinlich weniger, dass es 2 Methoden gibt, die nur diurch Groß- / Kleinschreibung unterschieden werden, viel schlimmer ist die Problematik bei Protected Membervariablen und Public Properties...

Siehe zu diesem Thema auch:
C# Upper- Lowercase in VB.NET

Aber ich denke nicht, dass Groß- / Kleinschreibung hier einen Kunden wirklich interessiert 😉

Grüße
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

0
767 Beiträge seit 2005
vor 15 Jahren

Eine Einschränkung hat das Ganze... VB.NET ist nicht case-sensitive, d.h. eine Methode TEST() und test() können nicht unterschieden werden. Beim Erstellen von VB.NET Code mag das irrelevant sein, versuchst du jedoch eine Assembly einzubinden, die in C# kompiliert wurde und eben genau diese beiden Test() Methoden mitbringt, so kannst du diese nicht in VB.NET aufrufen (keine von beiden).

mit dem Attribute
[assembly: CLSCompliant(true)]
kann man zumindest in eigenen C# assemblies sicherstellen, dass es auch von VB aus verwendbar ist.

loop:
btst #6,$bfe001
bne.s loop
rts

J
57 Beiträge seit 2008
vor 15 Jahren

Das Problem ist wahrscheinlich weniger, dass es 2 Methoden gibt, die nur diurch Groß- / Kleinschreibung unterschieden werden, viel schlimmer ist die Problematik bei Protected Membervariablen und Public Properties...

Bei Variablen ist das immer so eine Sache, stimmt schon. Für private Variablen Unterstrich oder nicht, bla bla wir kennen die Stories. 🙂 Allerdings kann man mit Me (this) private foo und public Foo in VB unterscheiden, sollte man mal an dem Punkt kommen.

630 Beiträge seit 2007
vor 15 Jahren

Hallo,

in VB.NET gibt es Optionale Parameter, welche von C# nicht unterstützt werden.
Soweit ich weiss sind diese aber bei guten VB.NET Programmierern sowieso verpönt.

Edit:

Im allgemeinen denke ich dass der Kunde nicht aus Jux VB.NET will. Kann ja sein dass die bestehende Codebasis VB ist, oder es vieleicht wie herbivore bereits angemerkt hat keine C# Programmierer beim Kunden gibt.

Gruss
tscherno

To understand recursion you must first understand recursion

http://www.ilja-neumann.com
C# Gruppe bei last.fm

Q
214 Beiträge seit 2006
vor 15 Jahren

Hallo,
oder der Kunde setzt VB.Net mit .Net gleich und sucht eigentlich nur eine .Net-Anwendung.

Möglichkeiten gibts viele, nur die Nachfrage beim Kunden hilft. Man muss beachten, dass nicht jeder Kunde soviel Kenntniss von .Net, Programmierung & Co. um genau zu wissen was er denn überhaupt will 😉

camelord Themenstarter:in
256 Beiträge seit 2006
vor 15 Jahren

Der Grund ist , dass der Kunde VB und keine C# Entwickler hat. Zur weiteren Pflege, sollte deshalb in VB codiert werden.
In dem Fall werd ich mir wohl demnächst die VB Syntax reinziehen müssen 🙁

Vielen Dank für die rege Teilnahme..

Gruß
Camelord