Laden...

C# 7.0 -- welche Features werden kommen

Erstellt von gfoidl vor 7 Jahren Letzter Beitrag vor 7 Jahren 8.402 Views
gfoidl Themenstarter:in
6.911 Beiträge seit 2009
vor 7 Jahren
C# 7.0 -- welche Features werden kommen

Hallo zusammen,

in What’s New in C# 7.0 gibt es eine Übersicht über die Features die mit C# 7.0 kommen werden.

V.a. bei Tuples und Pattern-Matching wurde angesetzt, so dass sich ein paar nette Möglichkeiten zum Coden ergeben können.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

3.511 Beiträge seit 2005
vor 7 Jahren

Moin,

das Einzig wirklich interessante sind die Switch Patterns. Local Functions machen den Code IMHO wesentlich unleserlicher. Tuples in der Form sind unnötig, da man doch besser eine eigene Klasse für die Rückgabe schreibt, sonst hat man überall immer nur x.Item1..x stehen (man sieht einfach nicht, was ItemX ist). Out Variables sind ganz nett. Und das Pattern Matching macht den Code auch verwirrender.

Im Prinzip alles nur Spielereien, die den Weg in meinen produktiven Code wahrscheinlich nie finden werden (bis auf das Switch Gedöns).

Gruß
Khalid

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

742 Beiträge seit 2005
vor 7 Jahren

Lies das mit den Tuples nochmal nach 😉 ...

16.807 Beiträge seit 2008
vor 7 Jahren

Ob was leserlicher ist oder nicht kommt vor allem drauf an, woher die Leute kommen. Andere Sprachen haben die Features teilweise schon immer.
.NET ist ja schon ziemlich komplett und wird jetzt einfach effizienter. Man muss die neuen Schreibstile ja nicht nutzen - ich finde sie jedoch super. Aber .NET wird von vielen Programmierern (gerade im Java- und Webbereich) nicht sonderlich gemocht, weil der Overhead an Code zB durch Klammern vergleichsweise hoch ist.
Deswegen finden hier aktuell einige in F# ihre Heimat.

Meine Meinung:

  • Tuples, Switch Pattern, Expression Bodies und out-Variables sind eine riesen Erleichterung. Da lässt sich ne ganze Menge Code mit sparen! Mit Item1 hat das nichts mehr zutun - bitte richtig anschauen.
  • Mit lokalen Funktionen wird es leichter und übersichtlicher Algorithmen zu schreiben

An .NET kann man funktional aktuell nicht mehr sooo viel verbessern. Es geht eigentlich nur noch im Syntaxzucker und der wird immer besser 😉

gfoidl Themenstarter:in
6.911 Beiträge seit 2009
vor 7 Jahren

Hallo Khalid,

das mit den Tuples finde ich nicht so blöd -- benannt werden können diese auch 😉
Es gilt jedoch schon abzuwägen ob diese Tuple-Rückgabe od. doch eine eigenen Klasse vewrendet werden soll. Bei Hilfsfunktionen bzw. internen Methoden kann ich mir das mit dem Tuple ganz gut vorstellen.

Etliche features (wie z.B. "Throw expressions", "Out variables") finde ich ganz nützlich, da der Code kompakter und mMn leserlicher geschrieben werden kann.

Mit allen Features kann ich mich im Moment aber noch nicht ganz anfreunden -- zumindest fällt mir da jetzt nicht allzu viel ein wo ich das verwenden könnte. Es wird aber mit Bestimmheit genügend potentielle Anwendungsfälle geben, sonst wäre diese nicht auf die Todo-Liste gekommen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

3.511 Beiträge seit 2005
vor 7 Jahren

OK, dass mit den Tuples habe ich tatsächlich falsch gelesen. Könnte an einiges Stellen doch recht sinnvoll sein.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

P
1.090 Beiträge seit 2011
vor 7 Jahren

Ich stehe den Tuples ein wenig skeptisch gegenüber.


(string first, string middle, string last) LookupName(long id)

im Vergleich zu


PersonNames LookupName(long id)

finde ich schon nicht so schön.

Auch ist die Frage wie es mit Änderungen aussieht.
Mit Wildecards sähe es ja so aus.


var (first, *, *) = LookupName(id1);

Wenn ich jetzt die Methode erweitert will, z.b. um Title.


(string title, string first, string middle, string last) LookupName(long id)

Muss ich ja, wenn ich es richtig sehe, alle aufrufe anpassen. Das finde ich jetzt nicht wirklich schön. Also bei public Methoden werde ich es wohl erst mal nicht verwenden. Bei private Methoden vielleicht, kommt auf die Methode an und ob da eine Klasse nicht besser geeignet ist.

Was die Local functions angeht.

Wenn ich beides Vergleiche.
Das


public int Fibonacci(int x)
{
    if (x < 0) throw new ArgumentException("Less negativity please!", nameof(x));
    return Fib(x).current;

    (int current, int previous) Fib(int i)
    {
        if (i == 0) return (1, 0);
        var (p, pp) = Fib(i - 1);
        return (p + pp, p);
    }
}

und das


public int Fibonacci(int x)
{
    if (x < 0) throw new ArgumentException("Less negativity please!", nameof(x));
    return Fib(x).current;

}

(int current, int previous) Fib(int i)
{
        if (i == 0) return (1, 0);
        var (p, pp) = Fib(i - 1);
        return (p + pp, p);
}


Finde ich ist kein großer unterschied. In der 1. Variante ist die Locale Funktion nicht separat zu testen (muss auch nicht unbedingt) und kann nicht wieder Verwendet werden. Finde ich auch nicht so schon.

Das mit dem Switch statements with Patterns finde ich wirklich gut.

p.s.
Abts Anspielung, das weniger Code besser ist (was ich auch schon in anderer Form so gelesen hab. Fine ich nicht unbedingt.

Hier mal ein Beispiel in Actually([/code]stackoverflow code colfstackoverflow code colf)


S;F@N

Finde ich deutlich schwerer zu Verstehen, als das gleiche in C++ umgesetzt.


void minmax(std::vector<int> v) {
    int min = v[0]; int max = v[0];
    for(std::vector<int>::iterator it = v.begin(); it != v.end(); it++) {
        if (*it < min)
            min = *it;
        if (*it > max)
            max = *it;
    }
    std::cout << min << ' ' << max << std::endl;
}

Wichtig für mich ist unterandern die Wartbarkeit. Und dazu gehört es das der Code gut lesbar und verständlich ist. Was man mit C# doch sehr gut machen kann (Ja es gibt auch Leute die es mit C# hinbekommen nicht lesbaren und verständlichen Code hinzubekommen, das sehe ich aber nicht als Feature von C# 😉 ). Und wenn dann ein paar Zeilen mehr Code sind wehen stört das wirklich.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.807 Beiträge seit 2008
vor 7 Jahren

Palin, es handelt sich hier im eine >>>>>Syntax-Erweiterung<<<<<.
Niemand zwingt Dich, dass nun alle Deine Quellcodes auf das neue Format migrierst oder "alte Dinge" nicht mehr nutzen darfst.

Du kannst weiterhin bei den "Tuples" mit einer Klasse als Rückgabe arbeiten. Aber wie sinnvoll ist so eine Klasse wie Du sie hier als PersonNames bezeichnest, wenn Sie genau ein einziges Mal verwendet wird?
Ein riesiger, vermeidbarer Overhead!

Es geht bei diesen Erweiterungen nicht darum, dass alles eingespart wird und das Prinzip der Objektorientierten Programmierung untergraben wird.
Es geht hier um Effizienz!

Abts Anspielung, das weniger Code besser ist (was ich auch schon in anderer Form so gelesen hab. Fine ich nicht unbedingt.

Und ja, diese Tuples können wirklich weiterhin in Form von Rückgabe-Klassen geschrieben werden, was auch sinn macht, wenn es eine entsprechende Nutzung gibt.
Eine Klasse zu schreiben, die eine Handvoll Male verwendet wird: Zeitverschwendung, zusätzlich zu testender Code! Häufige Nutzung, evtl im Rahmen eines SDKs: völlig legitim und vorzuziehen.

Nochmal zum Thema Effizient: ein Tuple mit 9 Elementen ist nicht effizient. =)
Natürlich nimmt man dann eine entsprechende Klasse zur Übergabe.

Der Grund der Local Functions ist hier deutlich besser erläutert: C# 7 Feature Proposal: Local Functions
Es geht hierbei einfach darum, dass die Klasse an für sich sauberer gestaltet und die Anzahl der privaten Hilfsmethoden minimiert wird.

Local functions would enhance the language by enabling you to define a function inside the scope of another function. That supports scenarios where, today, you define a private method that is called from only one location in your code. A couple scenarios show the motivation for the feature.

Ich finde das sehr gut, denn ich halte meinen Code heute schon modular; muss aber auf teilweise viele private Methoden zurückgreifen, obwohl die Methode nur an einer einzigen Stelle aufgerufen wird.
Damit das wiederum übersichtlich bleibt arbeite ich mit partial Klassen und verschiedenen Dateien.

P
1.090 Beiträge seit 2011
vor 7 Jahren

Palin, es handelt sich hier im eine >>>>>Syntax-Erweiterung<<<<<.
Niemand zwingt Dich, dass nun alle Deine Quellcodes auf das neue Format migrierst oder "alte Dinge" nicht mehr nutzen darfst.

Ist mir schon klar. Ich arbeite halt im Team und damit ist es nicht mein Quellcode sondern unserer. Und gegen Syntax-Erweiterung hab ich nichts. Ich finde nur es kann nicht schaden bevor man etwas benutzt sich Gedanken drüber zu mache. Vor- und Nachteile abzuschätzen und zu überlegen welche Auswirkungen sich daraus ergeben. Frei nach dem Motto: „Zwei mal Denken, einmal Schreiben“.

Du kannst weiterhin bei den Tuples mit einer Klasse als Rückgabe arbeiten. Aber wie sinnvoll ist so eine Klasse wie Du sie hier als PersonNames bezeichnest, wenn Sie genau ein einziges Mal verwendet wird?

Eine Klasse zu schreiben, die eine Handvoll Male verwendet wird: Zeitverschwendung, zusätzlich zu testender Code! Häufige Nutzung, evtl im Rahmen eines SDKs: völlig legitim und vorzuziehen.

Grundlegend genau so sinnvoll wie ein Interface, was nur von einer Klasse Implementiert wird. (Was bei einer Schichtentrennung mit IService, IRepository u.s.w. doch schon mal vorkommt)
Der Vorteil ist, das ich meiner Software flexibel und änderbar halte. Wenn ich die Tuples in einer Public Methode verwende (oder noch schlimmer zu dem in einem Intreface deklariert habe). Kann sie von jedem verwendet werden. Wenn ich an einer stelle jetzt einen zusätzlichen Rückgabewert mehr brauche, muss ich alle Aufrufe anpassen. (Und bei den Beispiel kann es gut Vorkommen, dass ich noch eine Anrede Brauche) Und genau das möchte doch ich eigentlich Vermeiden.

Software soll möglichst einfach änderbar sein. (Ich hoffe den kannst du zustimmen, wenn wir da andere Grundsätze Vertreten (z.B: möglichst wenig Quellcode). Reden wir nur aneinander Vorbei.

Und für Getter und Setter schreibe ich keine UnitTest. Sondern für Logik und die Steckt meist in den Funktionen. Damit wären wir dann beim nächsten Thema.

Ich finde das sehr gut, denn ich halte meinen Code heute schon modular; muss aber auf teilweise viele private Methoden zurückgreifen, obwohl die Methode nur an einer einzigen Stelle aufgerufen wird.
Damit das wiederum übersichtlich bleibt arbeite ich mit partial Klassen und verschiedenen Dateien.

Das mit dem Modularen kenne ich und ja auch ich hab viele private Methoden. Ich persönlich mag den Ansatz, in der Eigentlichen Methoden, sind dann nur die wesentlichen Schritte zu finden. Und wenn man noch aussagekräftige Namen für die Methoden findet, kann man den Quellcode gut lesen und sich auf das wesentliche Konzentrieren. Wenn einen dann doch die Details Interessieren, kann man auch einfach in die Methode springen. Das mit der partial Klasse mach ich jetzt nicht (meistens sind die Klassen nicht groß genug das es sich lohnen würde) , finde ich aber einen Interessanten Ansatz.

Aber genau das kannst du ja nicht machen machen wenn du Local Functions verwendest. Dann ist die Funktion ein Teil deiner Methode. Und du hast sie alle in einer Datei.

Dann kommt noch hinzu, das auch wenn du sie jetzt nur einmal Brauchst, es in Zukunft dazukommen kann das du sie auch noch in einer anderen Methode brauchst. Das heißt du must die eigentliche Methode anpassen und nach deinem Verlinkten Beispiel auch die Methode selber (Übergabeparameter).

Hinzu kommt ich kann die Methode im Zweifel nicht für sich Testen. (Kann man drüber diskutieren ob es sinnvoll ist, ich persönlich finde es schon ganz angenehm, das wenn eine Methode mal Komplexer werden sollte, ich sie auch alleine Testen kann. Ist sicher Geschmackssache.)

Dein Verlinktes Beispiel finde ich ehrlich auch nicht wirklich gut. Weil er meines Erachtens, die sinnvollste Alternative ausgelassen hat (Auch das Return Statement nach der Methode zu setzten finde ich nicht besonders geschickt, wenn hätte ich es nach dem letzten if gesetzt).

Aus


public static IEnumerable<TResult> SuperZip<T1, T2, T3, TResult>(IEnumerable<T1> first,
    IEnumerable<T2> second,
    IEnumerable<T3> third,
    Func<T1, T2, T3, TResult> Zipper)
{
    if (first == null)
        throw new NullReferenceException("first sequence cannot be null");
    if (second == null)
        throw new NullReferenceException("second sequence cannot be null");
    if (third == null)
        throw new NullReferenceException("third sequence cannot be null");
    if (Zipper == null)
        throw new NullReferenceException("Zipper function cannot be null");

    IEnumerable<TResult>Iterator()
    {
        var e1 = first.GetEnumerator();
        var e2 = second.GetEnumerator();
        var e3 = third.GetEnumerator();
        while (e1.MoveNext() && e2.MoveNext() && e3.MoveNext())
            yield return Zipper(e1.Current, e2.Current, e3.Current);
    }
    return Iterator();
}

Bekommen wir dann.


public static IEnumerable<TResult> SuperZip<T1, T2, T3, TResult>(IEnumerable<T1> first,
    IEnumerable<T2> second,
    IEnumerable<T3> third,
    Func<T1, T2, T3, TResult> Zipper)
{
    if (first == null)
        throw new NullReferenceException("first sequence cannot be null");
    if (second == null)
        throw new NullReferenceException("second sequence cannot be null");
    if (third == null)
        throw new NullReferenceException("third sequence cannot be null");
    if (Zipper == null)
        throw new NullReferenceException("Zipper function cannot be null");
 
        while (first.MoveNext() && second.MoveNext() && third.MoveNext())
            yield return Zipper(e1.Current, e2.Current, e3.Current); 
}     

Mir gefällt hier die 2. Variante besser.

Es geht bei diesen Erweiterungen nicht darum, dass alles eingespart wird und das Prinzip der Objektorientierten Programmierung untergraben wird.
Es geht hier um Effizienz!

Ja da stimme ich zu es geht um Effizienz.
Und was sind wirklich wichtige Punkte, für die Effizienz.
Gut lesbarer und verständlicher Quellcode. Quellcode wird einfach öfter gelesen als geschrieben.
Die Möglichkeit einfach Änderungen durch zuführen. Software ändert sich mit der Zeit.
Gute Unit Tests. Je später der Fehler gefunden wird, je teurer und schwieriger wird es ihn zu finden. Und bei Änderungen bekomme ich eine Rückmeldung ob noch alles so funktioniert wie es sollte.

Und hier sehe ich die Features, eher als Hindernis an. Man sollte an den Punkt schon genau wissen, was es bedeutet sie zu Benutzen.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.807 Beiträge seit 2008
vor 7 Jahren

„Zwei mal Denken, einmal Schreiben“

Bitte auch dran denken, dass C# nicht nur für Anwendungen mit zig Mitarbeitern verwendet wird.

Nicht jedem bewusst, aber durchaus verwenden Entwickler auch C# zum rapid development oder für schlanke Lösungen.
Und genau darauf zielt dieser Syntax-Zucker ab.

Keiner zwingt euch, dass ihr das verwendet - in eurem Quellcode.
Es geht hier darum, dass schlankerer Code umsetzbar ist. Natürlich muss man immer noch nachdenken und sich überlegen, ob evtl. der Syntaxzucker nicht kontraproduktiv für die Umsetzung ist; aber das galt schon immer und gilt immer.
Es ändert sich hier nichts.

Wenn Du sagst, dass solche Features hinderlich sind, dann lass das bloß keinen F# Fanboy sehen 😉
Manchmal muss man einfach auch mal über den Tellerrand schauen...

Die Köpfe hinter Roslyn bringen nichts in den Compiler, um Deinen Quellcode zu verschlechtern.
Korrekt Anwenden und nachdenken ist immer noch Deine Aufgabe.

Dahingehend: viel Erfolg beim Umsetzen.

P
1.090 Beiträge seit 2011
vor 7 Jahren

Die Köpfe hinter Roslyn bringen nichts in den Compiler, um Deinen Quellcode zu verschlechtern.
Korrekt Anwenden und nachdenken ist immer noch Deine Aufgabe.

Sehe ich auch so. (Auch wenn nicht alles was MS Entwickelt unbedingt sinnvoll ist, die haben auch schon genug Leichen auf dem Buckel).
Im Endeffekt ist es mein/unser Quellcode und ich/wir müssen entscheiden was wir verwenden.

Und um eine Entscheidung zu treffen kann einen eine Diskussion im Forum helfen.
Meine Einwende hab ich ja vorgebracht.

Und ja rapid development (RAD) hab ich jetzt nicht betrachtet. Genau sowenig wie du, wenn du zu der Verwendung einer 3-Layer Architektur Rätst mit der Implementierung von Endsprechenden Schnittstellen (Halte ich im allgemeine für eine gute Lösung). Auch wenn man einfach nur Daten aus der DB an die UI binden will.

Ich muss an dem Punkt aber auch gestehen, dass ich kein großer Fan von RAD Lösungen bin. Meiner Erfahrung nach, kommt man da schon recht schnell an seine Grenzen wenn es etwas kompliziertet wird. Und dann ist es im Enddefekt Teurer, als es direkt vernünftig zu entwickle.
(Erklärt auch mein Gehalt und ich denke mal du wirst auch nicht schlecht bezahlt 😉 )

Bei der Umsetzung, werde ich mich natürlich mit meinen Kollegen zusammen setzten und Besprächen was wir für Sinnvoll halten.
Und bei den Codereviews auch darauf achten, dass es Umgesetzt wird.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.807 Beiträge seit 2008
vor 7 Jahren

Und ja rapid development (RAD) hab ich jetzt nicht betrachtet. Genau sowenig wie du (..)

Mein Tagesgeschäft besteht auszum Großteil aus RD und RP - ich denk da immer dran und daher gefällt mir das, was mit dem Syntax hier passiert, so gut. 😉
Aber nette Unterstellung als Sidekick, danke 👍

PS: Overengineering ist auch teuer.
Dass ich hier im Forum das betone liegt daran, dass ich den Leuten die Bedeutung von Architektur nahe bringen will. Mir das jetzt vorzuhalten und die Diskussion auf diese Ebene zu schieben ist natürlich quatsch.

Daher entziehe ich mich nun dieser 🙂

O
79 Beiträge seit 2011
vor 7 Jahren

Viele der Neuerungen, die angedacht sind, finde ich super. Speziell die out-Geschichten, die immer etwas hakelig waren und der Stunt mit den Tuples.

Defnitives No-Go sind aber IMHO die lokalen Prozeduren. Ich kenne dieses Konstrukt aus Delphi, das ich über Jahrzehnte verwendet habe, bis ich in die C#-Schiene gewechselt habe. Und glaubt mir: Die Dinger taugen zu rein gar nichts. Sie machen den Code erheblich unlesbarer und sehr viel schwerer zu durchschauen.

Das mag zum Teil daran liegen, das ich sehr viel mit "altem" Code zu tun habe. Prozeduren mit > 10k LOC sind da wahrlich keine Ausnahme, sondern die Regel. Dann noch 22 lokale Prozeduren dazu und du siehst wirklich gar nichts mehr. Ich entnehme dann in aller Regel diese lokalen Prozeduren und mache Unit-interne Prozeduren daraus, was den Code solcher Monster-Funktionen fast immer erheblich einfacher zu durchschauen macht.

Glaubt einem mit 20 Jahren Erfahrung mit diesem Zeugs 😉 Dies ist einer der Syntax-Zucker-Elemente, die auf gar keinen Fall in meinen C#-Code gelangen.

2.078 Beiträge seit 2012
vor 7 Jahren

Ich denke, wer damit sparsam umgeht und die nicht ohne Grund nutzt, kann die durchaus nutzen.

So hab ich z.B. mal eine Methode gebraucht, die für eine ListView (WinForms) eine Column erstellt.
An sich keine große Aufgabe, allerdings mussten dafür noch zwei Properties gesetzt werden und ich brauchte diese Methode an genau zwei Stellen.
Dafür eine vollständig eigene Methode zu erstellen, fand ich unpassend, da ich lokale Variablen brauchte und diese Methode nur dort Sinn gemacht hat.
Wenn die Methode länger wird, kann man sie ja noch immer auslagern.

Natürlich kann man alles übertreiben, so sehe ich auch bei den Tupels eine große Gefahr, dass manche Leute die in Situationen nutzen, wo Klassen besser sind, oder Expression-Bodies, die länger sind als der Platz auf dem Desktop.

Man kann jedes Feature irgendwie falsch nutzen, aber mit bedacht eingesetzt, kann jedes dieser Features auch ein Vorteil sein.

P
1.090 Beiträge seit 2011
vor 7 Jahren

Und ja rapid development (RAD) hab ich jetzt nicht betrachtet. Genau sowenig wie du (..)

Mein Tagesgeschäft besteht auszum Großteil aus RD und RP - ich denk da immer dran und daher gefällt mir das, was mit dem Syntax hier passiert, so gut. 😉
Aber nette Unterstellung als Sidekick, danke 😮

PS: Overengineering ist auch teuer.
Dass ich hier im Forum das betone liegt daran, dass ich den Leuten die Bedeutung von Architektur nahe bringen will. Mir das jetzt vorzuhalten und die Diskussion auf diese Ebene zu schieben ist natürlich quatsch.

Daher entziehe ich mich nun dieser 😃){gray}

Also ich hab Beiträge von dir gelesen, bei dehnen du mehrmals Leuten dazu Anleitest eine „saubere“ Mehrschichtige Architektur zu verwenden (Was ich auch für richtig halte). Und auch bei Nachfrage, das sie eigentlich eine schnelle Lösung suchen. Keine schnelle Lösung geboten hast, sonder noch mal darauf hingewiesen hast, das sie „sauber“ Programmieren sollten.

Wo ich ja schon wieder Toleranter bin. Den DAL im PL zu benutzen ist nicht wirklich schön. Aber wenn ich nur Daten darstellen möchte OK, ich muss mir nur über dir Konsequenzen klar sein. Und dieses auch Kommunizieren.

Was das Overengineering angeht. Da hatten wir letztens auch ein Diskussion was den Logger angeht. Wo du darauf bestanden hast das DI und ein IOC Container die bessere Lösung ist. Anstelle eine einfachen Factory Patterns. (Ja hat mich gewurmt, ich könnte ja unrecht haben. Darauf hin hab ich mir ein paar Logger angeschaut. (Bieten alle das Factory Pattern an) und deinen Quellcode, sind auch keine Schnittellen vorhanden für einen Logger. Du schlägst da anderen Leuten Lösungen vor die du selbst nicht so umsetzt.)

Ich halte dir auch nicht vor, das du die Bedeutung von Architektur hervorhebst. Ich persönlich halte sie auch für sehr wichtig. Aber ich probiere es auch selber soweit ich kann in meinen Quellcode umsetzen. (Ja es gibt immer wieder Ausnahmen, bei denen einen andere Lösung besser ist. Und dann sollte ich auch die Verwenden.)

An de Punkt, erkläre den Leuten doch einfach wie es Theoretisch sinnvoll sein sollte und wie du es umsetzt.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.807 Beiträge seit 2008
vor 7 Jahren

Ich denke, wer damit sparsam umgeht und die nicht ohne Grund nutzt, kann die durchaus nutzen.

Man kann jedes Feature irgendwie falsch nutzen, aber mit bedacht eingesetzt, kann jedes dieser Features auch ein Vorteil sein.

Genau das ist es. =) Nested Functions kommt aus der Welt der funktionalen Programmierung.
C# hat davon gewisse Teile schon heute (und die einige Nutzen sie ohne, dass sie es wissen => Besserer C#-Code durch funktionale Programmierung)und kommt damit der funktionalen Welt etwas mehr entgegen.

gfoidl Themenstarter:in
6.911 Beiträge seit 2009
vor 7 Jahren

Hallo,

in New C# 7.0 features in Visual Studio “15” Preview 4 gibt es ein kurzes Programm-Beispiel, indem die Features in der Verwendung dargestellt werden.
Für die Übersichtlichkeit bzw. Veranschaulichung finde ich das Beispiel gut.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"