Home > C#, Patterns > [PL] Co będzie nowego w C# – Roslyn i moje trzy grumpy coins

[PL] Co będzie nowego w C# – Roslyn i moje trzy grumpy coins

csharpW końcu udało mi się ściągnąć większość videocastów z tegorocznego Build2014. Powoli, jeżdżąc do pracy pociągiem (o dziwo, pociąg coraz szybciej jeździ) oglądam sobie to co zassałem na tableciora i upajam się słodyczą i goryczką niektórych prezentacji. Jedną z takich prezentacji jest “The Future of C#” przedstawiająca nowości w nadchodzącym kompilatorze C#, a co z tym się wiąże także i w samym języku C#.

Nie chciałbym tutaj przedstawiać co być może będzie nowego w najbliższym wydaniu C#, bo to by było CTRL+C/GoogleBing Translate/CTRL+V tego co jest dostępne na samej stronie Roslyn. Przedstawię jedynie parę moich uwag odnośnie niektórych ficzerów. Należy pamiętać, że Roslyn nie jest jeszcze oficjalnym produktem i od czasu opublikowania tego postu może mocno się zmienić – dodając, zmieniając lub usuwając niektóre funkcjonalności.

Na co dzień, staram się kłaść duży nacisk na czytelność kodu – co nie znaczy, że nie mam zdolności do zaciemniania. Z tego względu będę tutaj opisywał jedynie uwagi co do czytelności niektórych rozwiązań.

1. Autoproperties i inicjalizacja

Propercje/propertisy/właściwości pojawiły się już jakiś czas temu w ostrym C. Upraszczają sporo pisanie kodu, który przechowuje wartości modelu/view modelu czy klas DTO. Problemem dotychczas było ustawienie wartości domyślnej dla autoproperty, którą należało przypisać w konstruktorze lub w backing-field. Teraz okaże się to o wiele prostsze:

public class Model
{
  public int Id { get; set; }
  public string Title { get; set; } = "Unknown";
}

Co się stanie jednak, gdy będziemy chcieli dodać backing-field do Title?… Nie widzę tego rozwiązania przy getter-onlly-properties. Jest to dla mnie co najmniej dziwne i nieintuicyjne. Wolę prymitywny return, jednak jest to pewnie jedynie kwestia przyzwyczajenia do składni i z czasem bym ją zaakceptował się przyzwyczaił.

Grumpy coin: nadal, jeżeli nasz property nie jest auto, to i tak musimy ustawiać wartość gdzieś w konstruktorze (i dobrze, że w tym niczego nie zmienili). Dodanie tego rozwiązania jest jak na razie spoko – jeszcze nie będę miał koszmarów w nocy.

2. Parametry na klasach

Podam jedynie przykład, chętnych zachęcam do źródeł i dokumentu z Roslyn. Wspomnę jedynie, że zespół devów Roslyn jeszcze nie wie jak ustawić składnię tego rozwiązania. Jak się tworzy normalną klasę, każdy wie, tutaj natomiast podajemy inny sposób, w jaki pola i propertisy mają zostać zainicjalizowane. (tak, nie ma konstruktora)

public class Customer(string first, string last, DateTime bday)
{
  public string First { get; } = first;
  public string Last { get; } = last;
  private DateTime _bday = bday;
}

Grumpy coin: Po prostu tak to jest nieczytelne dla mnie, jeszcze tak niezrozumiałe że aż nie chce mi się w to zagłębiać. Mój Grumpy level osiągnął maksimum i mówię zdecydowane nie.

3. Odwoływanie do metod statycznych

static_classes_everywhere

Dotychczas gdy wykorzystywaliśmy jakieś metody statyczne (głównie pewnie klasy Math, gorzej jakieś statyczne koszmarki z projektu) musieliśmy odwoływać się bezpośrednio przez nazwę klasy statycznej tak jak poniżej

Math.Abs(Math.Round(x))

Teraz będzie możliwość skrócenia tego do postaci ultra krótkiej

Abs(Round(x))

Grumpy coin: Jak dla mnie może być to mylące i nieczytelne. Z drugiej strony, czy używając extension-methods dla Linq interesuje mnie to gdzie leży Where, FirstOrDefault itp.? Bardzo lubię extension-methods i jego użycie stało się dla mnie normalne. Brakuje mi jednak wyróżnienia takiego extensiona w IDE. Wszystko jest fajne, do czasu gdy nie jest wykorzystywane w nadmiarze. Może to też prowadzić do problemów – co się stanie gdy nagle do klasy z ostatniego przykładu zostanie dodana metoda Round? Nie raz spotkałem się z problemem, że błędny extension Where był brany, i zamiast wykonywać zapytanie na IQueryable robione było na IEnumerable.

Pytanie: Czy jakiś programista VB ma na ten temat jakieś zdanie – to rozwiązanie jest w tam już od jakiegoś czasu dostępne w VB.

4. Zagnieżdżone deklaracje zmiennych

Jest to jeden z niewielu przykładów, które akurat mi się podobają. Często jakoś natykam się na wykorzystywanie metod TryGet czy TryParse. Mając jakiś słownik, z dosyć skomplikowanym typem lub gdy chcę parsować zmienną typu int, to muszę ją zadeklarować przez wykorzystywaniem w TryParse.

MyPreciusAndSelfExplanatoryDelegate handler;
if (_handlers.TryGet(out handler))
{
  handler(x);
}

Jest to mało estetyczne, zajmuje jedną zbędną linię (to dla mnie dużo), i na dodatek definicja ta nie jest dalej wykorzystywana. Chciałbym użyć tej samej nazwy dalej lub ograniczyć dostęp do niej jedynie w scope wewnątrz pętli if. Dodatkowo muszę podawać typ przy deklaracji, zamiast użyć mojego kochanego var. Teraz może okazać się prostsze:

if (_handlers.TryGet(our var myPreciusDelegate)) 
{
  myPreciusDelegate();
}

5. Filtrowanie wyjątków – wsparcie dla EDD

W projektach staram się unikać tworzenia na ogromną skalę swoich własnych typów wyjątków lub komunikacji za pomocą wyjątków. Jak definiuję typy wyjątków, to definiuję konkretną hierarchię klas i określam wyjątki, które definiują konkretne problemy. Są jednak projekty, które bazują na komunikacji z wyjątkami (tak zwany Exception Driven Development) – żeby poinformować o jakimś stanie, to wyrzucany jest wyjątek (mimo wszystko lepsze jest wyrzucanie, niż połykanie). Jednak nie czepiając się już szczegółów… prawdopodobnie będzie możliwość dodania tak zwanego filtra, który będzie determinował, czy jeżeli wystąpi dany wyjątek, to czy blok catch danego wyjątka ma go obsłużyć, czy też nie

try { ... }
catch (SomeExcetion ex) if (someFilter(ex)) 
{ ... }

Pytanie: W sumie jak często jest to wykorzystywany ten mechanizm w VB i F#?

Co więcej

Jest jeszcze parę rzeczy, które mogą pojawić się w najbliższym wydaniu C#. Jednak Roslyn to nie jedynie C#. Warto przejrzeć chociaż początek prezentacji, żeby zobaczyć co Roslyn oferuje, a oferuje między innymi możliwość formatowania kodu, wg określonych reguł (co wiąże się z parsowaniem gramatyki i składni języka C#).

[1] – Link do Videocast z Build 2014

[2] – Link do projektu Roslyn

[3] – Link do projektu na Codeplex

Tags:
  1. matgren
    April 11, 2014 at 07:48

    Fajny artykuł. Co do tych nowinek w C# to imo nie urywa.

    • April 11, 2014 at 08:15

      Zgadzam się z Tobą co do tych nowinek.
      Szału nie ma, zobaczymy może coś się jeszcze pojawi ciekawszego w C#.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: