Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
Kontrowersyjny esej o kodzie czytelnym, część 2: VAR
Słowo kluczowe var jest sposobem na uniknięcie długich nazw typów podczas deklarowania zmiennych lokalnych. Dzięki niemu unikamy dwukrotnej specyfikacji typu, co może być przydatne w np. wypadku deklarowania zmiennej typu Dictionary<string, Dictionary<string, int>>.

Czy długie nazwy typów są naprawdę nieuniknione? Czy słownik słowników to dobry typ dla zmiennej lokalnej? Jeśli deklarujemy zmienną będącą złożeniem dwóch kolekcji, potrzebujemy umieścić gdzieś logikę odpowiedzialną za manipulowanie nią. Zwykle robimy to w jakichś prywatnych metodach. Zamiast tego, stwórzmy nowy typ opakowujący nasze skomplikowane złożenie i nadajmy mu prostą nazwę – na tyle krótką, aby dwukrotne jej umieszczenie w deklaracji zmiennej nie było bolesne.

Jeśli jednak jesteśmy fanami var – OK. Jeśli takie są standardy kodowania w Twoim zespole – OK. Pamiętaj tylko o jednym: stosowanie var przy deklaracji zmiennej której wartość początkowa jest wynikiem wywołania metody bardzo zmniejsza czytelność kodu. Skąd ktoś ma wiedzieć jakiego typu jest zmienna result, jeśli jej deklaracja wygląda tak: var result = GetSomethingFromSomePlace()? Tu dochodzimy do jednej z pozytywnych cech słowa kluczowego var. Jest nią według mnie bezlitosne eksponowanie problemu nic nie mówiących nazwy zmiennych. O ile moje dywagacje na temat var są wyrazem moich osobistych subiektywnych odczuć, o tyle plaga bezmyślnego nazywania elementów kodu jest bezdysusyjnie zła i jako taka powinna być tępiona z całą stanowczością.

Opublikowane 22 października 2009 13:41 przez simon

Filed under:

Komentarze:

# Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 22 października 2009 15:06

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 22 października 2009 16:10

Moim zdaniem to nie słówko var powinniśmy "tępić z całą stanowczością", a tego kto nazywa metody w stylu "GetSomethingFromSomePlace()". Kod powinien być samoopisujący się, więc jeśli widzę

Dictionary<string, Dictionary<string, int>> które jest inicjowane przez jakąś prywatną metodę fabrykującą GetSomethingFromSomePlace() to nadal NIC nie wiem. Nie widzę nic złego w użyciu słówka var w ludzki sposób np:

var products = GetPromotionalProducts()

Widzę taki kod i spodziewam się co robi taka metoda, chcę wiedzieć więcej (a może mi to już wystarczy)? Wtedy wciskam F12 (albo nie).

Darek Tarczyński

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 22 października 2009 18:44

@Darek

Uściśliłem nieco treść mojego posta, aby było jasne, że to bezmyślne nazewnictwo powinniśmy tępić. Słowa var osobiście subiektywnie nie lubię, bo zachęca do złego;) niewinnych młodych programistów:P Ja np. widziałem ostatnio var użyte zamiast "int" lub "Guid". To już wg mnie mocna przesada.

simon

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 22 października 2009 20:22

Klasyczny przypadek nadmiernego wykorzystywania pomocniczych struktur języka. Nadgorliwość gorsza od faszyzmu?

reVis

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 10:13

@reVis (btw pozdrowienia po starej znajomości)

Po to języki ewoluują, aby korzystać z tego co oferują. Poza tym var nie jest pomocniczą strukturą, ale pełnoprawnym członkiem języka C#.

Dla mnie na przykład var jest nieocenione przy testach jednostkowych, ponieważ zaoszczędza sporo miejsca i pisania, a kod jest IMHO bardzo czytelny:

var addresses = new Dictionary<String, String> {

               { "first@address.com", "First user" },

               { "second@address.com", "Second user" },

               { "third@address.com", "Third user" }

           };

Jest absolutnie jednoznaczne i w moim pojęciu czystego kodu - czyste ;)

matma

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 10:42

@matma

Twój przykład jest wg mnie OK. Widać o co chodzi. Moje wątpliwości są związane z tym, że sprawia, że coś co do tej pory było bolesne, np. Dictionary<Dictionary<string, string>> staje się o wiele mniej bolesne i ludzie mogą dać się skusić. W moim mniemaniu celem wprowadzenia var do języka są typy anonimowe, gdzie var jest niezbędne. W pozostałych wypadkach wolę go unikać.

PS. Moja osobista opinia: z var jest jak Linq--wygląda świetnie, ale na dłuższą metę powoduje płacz i zgrzytanie Zergów.

simon

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 11:06

Generalnie chyba nie ma co tak się martwić. Mocną i ważną zaletą var, która chyba lekko została w powyższym tekście pominięta jest fakt, że cokolwiek by się nie działa to co naprawdę kryje się pod danym var jest zawsze jednoznacznie wyznaczone. Stąd da się automatycznie pozbyć wszystkich varów z kodu, poza obiektami anonimowymi i już. Podobnie w drugą stronę - da się automatycznie zastąpić wszystkie jawne deklaracje typów słówkiem var, tam gdzie to tylko możliwe. Narzędzie typu ReSharper świetnie sobie z tym radzą...

houp

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 11:10

Mozliwosc zastepowania skomplikowanych nazw typow, jak: Dictionary<string, Dictionary<string, int>>, przez var to tylko bonus. Glowym celem jest oblsuga typow anonimowych jako takich.

klm_

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 11:16

@simon

Abstrahując od dziwnych konstrukcji typu Dictionary<Dictionary...>, wprowadziłbym typ pomocniczy, ale nie o tym :)

We mnie dużo większy płacz powoduje na siłę trzymanie się "standardów" - zapytanie do bazy tylko poprzez stored proc, połowę logiki w bazie a druga połowę w aplikacji, i oczywiście używanie ADO wszędzie, bo po co ORM :(

(przykład niestety z autopsji).

Nie twierdzę że Linq jest odpowiedzią na wszystko, jak również że var musi być stosowany zawsze, ale należy spojrzeć na to, iż w stronę anonimowego bądź dynamicznego programowania zbliżamy się codziennie, gdyż jest ono po prostu wygodniejsze.

Na prawdę - wolę debugować linq, niż ADO + logikę w bazie ;)

Jak jeszcze raz podkreślam jest to moje zdanie.

matma

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 14:03

@matma

"Na prawdę - wolę debugować linq" - jak dla mnie to jesteś bohaterem ;-)

marekpow

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 15:37

Wszystkiego trzeba używać z rozsądkiem. Ani słówko VAR ani inny syntactic sugar nie jest po to żeby szkodzić, tylko MOŻE nam pomóc.

Darek Tarczyński

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 października 2009 15:53

@matma

Moim zdaniem ORM-y stworzono po to, aby nikt nigdy nie potrzebował korzystać z LINQ. Dobry ORM sprawi, że tworzenie zapytań ad hoc będzie na tyle trudne, że łatwiej będzie niezbędną logikę zamodelować na poziomie modelu domeny.

Moje doświadczenie z LINQ: 99% osób zapomina o tym, że IEnumerable to nie to samo co IQueriable i że w C# nie sposób odróżnić metody która przyjmuje delegata od metody, która przyjmuje ExpressionTree

simon

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 listopada 2009 14:40

Moim zdaniem waznym jest, zeby nie zapominac, ze w dojrzalym, duzym projekcie kazde dodanie nowej klasy to nowy zestaw unit testow, support, dokumentacja itp, oraz zaleznie od tego jak dodane to zwiekszenie call stacka i/ lub drzewa dziedziczenia. Jesli projekt jest wystarczajaco duzy to warto sie zastanowic, czy dodanie takiego malego slowka jak 'var', ktore powoduje ze tylko trzeba sie uwazniej przyjrzec prawej stronie rownania i ewentualnie dodanie bardziej tresciwego komentarza, nie jest przypadkiem tansze od dodania nowego typu, ktory czesto jest zbedny a zwieksza koszty utrzymania produktu. Zatem byle rozsadnie :)

Zwirek

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 23 listopada 2009 20:15

@Zwirek

W jaki sposób var pozwala "zaoszczędzić" na klasach? Chodzi Ci o możliwość tworzenia klas anonimowych?

simon

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 24 listopada 2009 09:56

Nie :)

Chodzi mi o ten fragment:

"Czy długie nazwy typów są naprawdę nieuniknione? Czy słownik słowników to dobry typ dla zmiennej lokalnej? (...) Zamiast tego, stwórzmy nowy typ opakowujący nasze skomplikowane złożenie i nadajmy mu prostą nazwę – na tyle krótką, aby dwukrotne jej umieszczenie w deklaracji zmiennej nie było bolesne."

:) Niekiedy lepszy var, by ukryc ten dlugi typ, ot tyle.

Zwirek

# re: Kontrowersyjny esej o kodzie czytelnym, część 2: VAR @ 27 lutego 2011 12:14

A ja bardzo polubiłem var, mimo pierwotnego sceptycyzmu (jakoś tak kojarzyło mi się głównie z VB).

Dzięki var szybciej piszę kod i skupiam się na zadaniu, które ma wykonać a nie na typach które obrabia. O zgodność typów zadba kompilator, o czytelność kodu dbają nazwy zmiennych i metod.

A skoro już raz np.w metodzie GetProducts zdefiniowałem typ, to po co mam go jeszcze raz ustalać w każdym miejscu, w którym ją wykorzystuję?

Są takie miejsca w kodzie, gdzie pobiera się jakieś zmienne po to żeby je np. zagregować i przesłać dalej, albo wypełnić jakąś kolekcję, wtedy naprawdę jest mi wszystko jedno co to za typ, i słówko var dokładnie to mówi.

Nie znaczy to, że stosuję var zawsze i wszędzie, ale na tyle często żeby uznać je za przydatne :)

twk

Komentarze anonimowe wyłączone