C# C# 8 + VS2019 am 02.04.2019

  • Ersteller Ersteller hroessler
  • Erstellt am Erstellt am
H

hroessler

Gast
Hallo zusammen,
für alle interessierten zur Info:

Microsoft veröffentlicht morgen, 02.04.2019 die Releases von C#8 und Visual Studio 2019. Viele der C# Neuerungen sind schon aus anderen Programmiersprachen (z.B. Java oder Python) bekannt und sind daher evtl. nicht ganz so aufregend. Dennoch ist natürlich alles willkommen, was das Entwicklen mit C# einfacher und schneller macht.

Ich bin schon sehr gespannt :)

greetz
hroessler
 
  • Gefällt mir
Reaktionen: Kalsarikännit, new Account() und Chriz
Am meisten an VS19 regt mich das neue Farbschema des Codes auf.
Selbst wenn ich es in den Optionen auf Standard zurücksetze, ist es beim nächsten Start wieder quietschebunt. Was soll das?
 
@new Account(): Schon, allerdings finde ich die Art und Weise wie MS dies eingeführt hat schon ziemlich dämlich. Wieso muss ich bestehenden Code ändern damit der C# 8 Compiler nicht massenweise Fehler oder Warnungen ausspuckt?

C#:
string abc = "Hallo Welt" //C# 7 --> OK
string abc = "Hallo Welt" //C# 8 --> OK

string abc = null; //C# 7 --> OK
string abc = null; //C# 8 --> Error oder Warning

string? abc = null; //C# 8 --> OK

greetz
hroessler
 
Zuletzt bearbeitet von einem Moderator:
Imho, weil man ihn ändern sollte. Würde man das nicht machen, würde sich das Management bestehender Codebasen einen feuchten Dreck darum kümmern ihre technischen Schulden zu tilgen ;)

MS hat sich bestimmt ähnliches gedacht.

Es sind nur Warnungen, oder? Keine Fehler.

PS: Heute ist ja der 1. April - Reddit C# ist im VS Style: https://www.reddit.com/r/csharp
 
@newAccount(): Wow, bezahlt mir Microsoft die Stunden die ich benötige um meine ganzen Projekte umzuschreiben? Wohl eher nicht! Ein Bruch bestehender Codebasis ist immer hässlich und vor allem
aufwändig und teuer.

Zudem war es seither auch schon möglich ohne null zu Entwickeln. Nur halt nicht ohne direkte Unterstützung des Compilers. Ich mache das eh schon eine Weile. Das ist primär eine Frage der Disziplin des Entwicklers.

C#:
string abc = string.Empty; //Das ging schon immer!!!
EventArgs e = EventArgs.Empty; //Das ging schon immer!!!

Action<string> = (text) => ; //Default für Lambda

EigeneKlasse istanz = EigeneKlasse.Default; //Das ging auch schon immer


Ob Warnung oder Fehler ist meines Wissens nach einstellbar. Wobei ich der Meinung bin, dass Warnungen spätestens im Release wie Fehler zu behandeln sind. Somit für mich Warnung == Fehler!

greetz
hroessler
 
hroessler schrieb:
Zudem war es seither auch schon möglich ohne null zu Entwickeln. Nur halt nicht ohne direkte Unterstützung des Compilers. Ich mache das eh schon eine Weile.
Dann bekommst ja eh nur selten die Warnings.

Andererseits ist es auch die Frage, ob es schlau ist, grundsätzlich null zu vermeiden.
Gerade, wenn man Optionalität andeuten möchte, wäre imho ein Nullable angebrachter als string.empty, da man einen leeren String genauso verwenden kann wie einen gefüllten String. Mit null passiert dir das nicht so einfach.

hroessler schrieb:
Wow, bezahlt mir Microsoft die Stunden die ich benötige um meine ganzen Projekte umzuschreiben?
Als vorbildlicher Entwickler hättest du das sowieso gemacht (IMHO), so what?
Paar Fragezeichen einfügen da ;)

Wenn ich mir C++ anschaue, hätte ich mir gewünscht, dass die Entwickler eher so wie hier vorgegangen wären, statt sich völlig der Trägheit der Entwickler und Projekte unterzuordnen.
 
new Account() schrieb:
Dann bekommst ja eh nur selten die Warnings.
Naja, ich habe noch ältere Projekte bei denen ich das nicht gemacht habe!

Andererseits ist es auch die Frage, ob es schlau ist, grundsätzlich null zu vermeiden.
Gerade, wenn man Optionalität andeuten möchte, wäre imho ein Nullable angebrachter als string.empty, da man einen leeren String genauso verwenden kann wie einen gefüllten String. Mit null passiert dir das nicht so einfach.
Es gibt aber keine andere Möglichkeit null zu vermeiden. Primär ist das aber auch eine Definitionsfrage. Ich habe für mich definiert, dass ein Leerstring einen "leeren" Wert darstellt (wie null), genause wie Klasse.Default quasi null ist. Das funktioniert ohne Probleme, wenn sich alle beteiligten daran halten. So in der Art wirst du das bei den non Nullable Referencetypes auch machen. Der Compiler initialisiert die Objekte ja nicht für dich, sondern schimpft nur! :)

Als vorbildlicher Entwickler hättest du das sowieso gemacht (IMHO), so what?
Paar Fragezeichen einfügen da ;)
Ich sollte schon ein Feature benutzen dass es erst morgen geben wird??? :confused_alt:

Wenn ich mir C++ anschaue, hätte ich mir gewünscht, dass die Entwickler eher so wie hier vorgegangen wären, statt sich völlig der Trägheit der Entwickler und Projekte unterzuordnen.
Hier verstehe ich den Kontext nicht...

greetz
hroessler
 
@hroessler Dann nutz das neue Feature doch einfach nicht für deine alten Projekte.
Bislang musstest du es für alte Projekte explizit per

XML:
<PropertyGroup>
  ...
  <NullableReferenceTypes>true</NullableReferenceTypes>
  <LangVersion>8.0</LangVersion>
</PropertyGroup>

in den Projekteinstellungen aktivieren. Hat sich das geändert? Kann man es nicht mehr ausschalten?
 
hroessler schrieb:
Es gibt aber keine andere Möglichkeit null zu vermeiden.
Ich würde auch gar nicht null vermeiden wollen, sondern es eben nur dann verwenden, wenn es Sinn macht.
Den Default Wert als "null" zu verwenden halte ich eher für eine Bad Practice.
V.a., was, wenn der Default Wert ein gültiger Wert ist? Auf einen anderen Wert ausweichen (-1 für int)?
Was, wenn der Defaultwert anders als geplant doch Sinn macht?
Lieber gleich ordentlich, d.h. explizit statt implizit. Eigene Definitionen kann man versehentlich ignorieren. Bei Kompilerfehlern wirds schon schwieriger ;)
hroessler schrieb:
So in der Art wirst du das bei den non Nullable Referencetypes auch machen.
Nope.
https://docs.microsoft.com/en-us/do...1?redirectedfrom=MSDN&view=netframework-4.7.2
oder manchmal macht auch Polymorphismus Sinn, kommt auf die Situation an.

hroessler schrieb:
Ich sollte schon ein Feature benutzen dass es erst morgen geben wird??? :confused_alt:
Ich meine als vorbildlicher Entwickler würdest du sowieso auf Nullables migrieren, egal ob man jetzt Warnings bekommt oder nicht ;)
 
Zuletzt bearbeitet:
Ok Guys,
ich habe jetzt keine Lust auf eine Diskussion bzw. ins klein klein von Entwicklungsmethoden einzusteigen. Wie es scheint haben wir hier unterschiedliche Meinungen, Vorgehensweisen und Erfahrungen. Und das ist auch Ok so.

Nur: Microsoft bricht hier mit bestehender Codebasis, das ist das was ich an der Einführung von non Nullable Types angemerkt habe.

greetz
hroessler
 
Wieder Hauptsache meckern? Es wurde doch bereits erwähnt, dass man das explizit aktivieren muss. Tu es halt nicht, wenn die Projekte zu groß für eine Umstellung sind.
 
Die KeyNote von VS2019, ziemlich interessant, da es mehr oder weniger ein Rundgang durch die betroffenen Teams ist:
 
Zurück
Oben