Legacy code a lambda body expression

Cześć,

Natrafiłem na taki jak poniżej obrazek...
Generalnie to z lewej, czyli chyba "legacy code", jest zrozumiałe i przejrzyste. Niestety to z prawej jest dla mnie dość skomplikowane. To są chyba wyrażenia lambda? Poleca ktoś jakieś materiały na poziomie intermediate które będą zawierać te zaawansowane pojęcia?
Kolejny pytanie, trochę bardziej heurystyczne. Jak bardzo jest wymagana znajomość pisania kodu tak jak po prawej w praktyce? Czy jeśli ktoś uczy się/umie programować tak jak po lewej. To znaczy, że dla niego rynek pracy prędzej czy później się zamknie?

Już prędzej [CIACH!] nauczy się frontendu niż w najbliższym czasie C# 9/8 będzie czymś standardowym na rynku.

Nie masz co się obawiać, bo ta składnia po prawej to tylko skracacze kodu i sposoby na zwiększenie ekspresywności.

Są inne ważniejsze featuresy nowego C# niż Top-Level Statements czy Switch Expression z prawego obrazka.

Jeżeli chodzi o Top-Level Statements to ich celem (afaik) jest po prostu ułatwienie pisania prostych 1 plikowych programów

Switch Expression

gornada napisał(a):

Cześć,

Natrafiłem na taki jak poniżej obrazek...
Generalnie to z lewej, czyli chyba "legacy code", jest zrozumiałe i przejrzyste. Niestety to z prawej jest dla mnie dość skomplikowane. To są chyba wyrażenia lambda? Poleca ktoś jakieś materiały na poziomie intermediate które będą zawierać te zaawansowane pojęcia?

Lol.
Tak się kończy rzeźbienie jednego paradygmatu. Poczytaj o funkcyjnym na początek zanim weźmiesz się za całą resztę.

gornada napisał(a):

Kolejny pytanie, trochę bardziej heurystyczne. Jak bardzo jest wymagana znajomość pisania kodu tak jak po prawej w praktyce? Czy jeśli ktoś uczy się/umie programować tak jak po lewej. To znaczy, że dla niego rynek pracy prędzej czy później się zamknie?

Nie zamknie. Ale nie idąc z nowszymi wersjami języka trochę się skurczy. Poza tym to co po lewej nadal będzie obsługiwane. Najwyżej koledzy wytkną Cię palcami, że robisz coś w 20 linijkach zamiast w 6.

PS. Ucz się programowania, a nie składni. Ja nie piszę w C# od ponad 4 lat, a doskonale rozumiem obydwa zapisy.

Dokładnie, jak wyżej i @WeiXiao, nie przejmuj sie tak bardzo, sa ważniejsze rzeczy w programowaniu, design, clean code, etc... Jak tak bardzo jesteś dociekliwy, to przeczytaj w dokumentacji. Acha, fajna namespace XD :-)

Ogólnie: aby zrozumieć switch expressions poszukaj pod hasłem "pattern matching". Jak wspomniał @purrll - to taki ficzer zaciągnięty z języków funkcyjnych.

gornada napisał(a):

Kolejny pytanie, trochę bardziej heurystyczne. Jak bardzo jest wymagana znajomość pisania kodu tak jak po prawej w praktyce? Czy jeśli ktoś uczy się/umie programować tak jak po lewej.

Jeśli trafisz do ogarniętej firmy gdzie używają Resharpera (polecam się z tym zapoznać jak już nauczysz się podstaw, możesz sobie triala zainstalować na miesiąc) to on ci prawdopodobnie sam podpowie że kod który napisałeś może zostać skrócony.

O ile czasami, może, elementy kodu po prawej będą przydatne, to nie widzę sensu w pisaniu w ten sposób zamiast kodu po lewej.

Nic to w tym przypadku nie daje, a kod zaciemnia. Funkcyjniacy niech sobie piszą w F#, po co tak psuć C#...
To już jest naprawdę faza feature bloat.

gornada napisał(a):

To są chyba wyrażenia lambda? Poleca ktoś jakieś materiały na poziomie intermediate które będą zawierać te zaawansowane pojęcia?

Lambdy są dostępne w C# dwa razy dłużej niż @WeiXiao żyje, konkretnie od 2007 roku. Nie wydają mi się zaawansowane, a na pewno są prostsze niż mechanizmy, których trzeba było używać przed nimi.

Kolejny pytanie, trochę bardziej heurystyczne. Jak bardzo jest wymagana znajomość pisania kodu tak jak po prawej w praktyce? Czy jeśli ktoś uczy się/umie programować tak jak po lewej. To znaczy, że dla niego rynek pracy prędzej czy później się zamknie?

Jeśli ktoś nie śledzi zmian w języku, to znaczy, że się nie rozwija, więc najprawdopodobniej zmniejsza swoje szanse na zatrudnienie. Znać trzeba wszystkie sposoby zapisu, bo w pracy trafia się na kod powstały w różnych czasach według różnych standardów, i trzeba go umieć czytać ze zrozumieniem.

Azarien napisał(a):

To już jest naprawdę faza feature bloat.

czy ja wiem? wiele razy narzekałem dlaczego switch jest taki ograniczony, dla mnie na +

O ile Switch Expression często jest przydatny tak w tym przypadku według mnie został niepotrzebnie użyty i zaciemnia kod. Operator trójargumentowy ?: w zupełności by wystarczył.

Bo oczywiście, operator trójargumentowy nie zaciemnia kodu :-D

Tu masz połączenie kilku featerów na raz - ogarniaj je jeden po drugim. Pierwszy z nich jest akurat wycelowany w początkujących i ma zmniejszyć próg wejścia żeby zamiast:

using System;

namespace XD
{
    public class Program
    {
        public static void Main(string[] args) {
            Console.WriteLine("Hello World");
        }
    }
}

można było napisać:

using System;

Console.WriteLine("Hello World");

Nie wiem czy to w ogóle wejdzie bo o ile wiem to jest jeszcze na etapie propozycji, ale nie wszystkie nowe ficzery przy okazji skracania składni komplikują kod. Najważniejsze żebyś umiał taki kod czytać, w produkowaniu takiego kodu jak wyżej już ktoś wspomniał mogą pomóc codefixy i resharpery. Plusem dla kogoś kto siedzi w C# od kilkunastu lat jest to że te sugar syntaxy były wprowadzane wolno i stopniowo - do tego samemu widziało się ich sens i jak mogą skrócić kod więc czekało się z niecierpliwością na kolejną wersję języka. Nauczenie się tego wszystkiego na raz może być faktycznie przytłaczające więc polecam po kolei dojść do najnowszej wersji języka analizując jakie były zmiany wprowadzane po drodze. Przy okazji pomoże Ci to w poprawianiu znalezionego starego kodu na necie i nie będziesz miał wątpliwości czy

event += new SthDelegate(Metoda) to to samo co event += Metoda (niedawno ktoś tu na forum próbował przekonać że nie)

WeiXiao napisał(a):

Już prędzej [CIACH!] nauczy się frontendu niż w najbliższym czasie C# 9/8 będzie czymś standardowym na rynku.

c# to nie java - wersja języka nie jest sztywno powiązana z wersją runtime'a - jeśli tylko masz VS 2019 i włączone aktualizacje to nikogo nie musisz prosić o pozwolenie na użycie nowych składni języka - w przeciwieństwie do javy niekoniecznie zawsze wymaga to zmiany konfiguracji builda, instalowania nowszych wersji jre i dziesiątek pozwoleń. nowe wersje języka "wchodzą na rynek" dość szybko

obscurity napisał(a):

c# to nie java - wersja języka nie jest sztywno powiązana z wersją runtime'a - jeśli tylko masz VS 2019 i włączone aktualizacje to nikogo nie musisz prosić o pozwolenie na użycie nowych składni języka - w przeciwieństwie do javy niekoniecznie zawsze wymaga to zmiany konfiguracji builda, instalowania nowszych wersji jre i dziesiątek pozwoleń. nowe wersje języka "wchodzą na rynek" dość szybko

od kiedy? roku? 2? od czasów Roslyn? bo na pewno w .NET w okolicach 4.5 tak nie było :P

Pocieszę Cię że mało kto ogarnia to wszystko na raz. Przykładowo można taki kod:

var obj = new Ob();
obj.Prop = 5;

skrócić do

var obj = new Ob { Prop = 5 };

i o Object Initializer Syntax wie pewnie z 99% programistów tego języka
Że można skrócić

var list = new List();
list.Add(5);

do

var list = new List { 5 };

(Collection Initializers) wiedzą też prawie wszyscy (choć poznałem wielu którzy usilnie wciskają tam jeszcze dodatkowe nawiasy). To że samemu można zadeklarować metodę .Add w obiekcie który nie jest listą i przyjąć więcej niż jeden parametr wie już może połowa.
A to że można połączyć te dwa i dodawać do kolekcji przy tworzeniu obiektu i to nawet tych które są read-only:

var sqlCommand = new SQLCommand();
sqlCommand.Parameters.Add("abc", "value1");
sqlCommand.Parameters.Add("def", "value2");

=>

var sqlCommand = new SQLCommand {
    Parameters = { // znak równości wbrew pozorom nie stworzy nowej listy tylko wywoła .Add na istniejącym obiekcie
        {"abc", "value1" },
        {"def", "value2" }
    }
};

wie może jakieś 5%, nawet twórcy resharpera zdają się nie wiedzieć bo takiej podpowiedzi nie ma.