Czytaj kod jak książkę

Czytakpisanyblogbyłbyczytelnydlawas?
CzyMożeTakBędzieCzytelniej?
A_Może_Część_Z_Was_Preferuje_Taki_Zapis?
MgSZłŻITkLpjBdzZCztlnscNzTrz. (Aktualnie już nie pamiętam co tutaj napisałem)

Dlaczego gdy piszemy do ludzi potrafimy używać pełnych wyrazów, pełnych zdań, samogłosek i spółgłosek i nie skracamy. Natomiast gdy tylko siada jeden z drugim (ja nie jestem święty), piszemy P=ObsłużW(1,false, new Coś());
NIE MA SZANSY ŻE KTOŚ TO ZROZUMIE. NIE-MA.

Czy to jest wstyd pisać czytelny kod? Czy panuje u nas takie zdanie, że jak jesteś pro, to twojego kodu nikt nie może zrozumieć? Dostaje czasem jakiś kod do przejrzenia, żeby powiedzieć czy warto czy nie warto. Zdarzają się rozwiązania zadań oparte na if-else-if-else-if-else i globalnych zmiennych. Albo stringi wszędzie, czy 1,2,3,4,5,6 zamiast sensownego enuma.

Czemu tak jest? Lenistwo? Lans? Czy może tak jak napisał kiedyś mój dobry kolega Hanselman piszemy taki kod żeby czuć się nie zastępowalnymi. To totalny absurd! Ja chcę skoczyć i zmienić swój projekt, albo przez dowiezienie go do końca albo oddanie komuś po drodze. Staram się za wszelką uczynić go tak prostym żeby każdy mógł go przejąć.  Nie zmarnować nawet godziny na niepotrzebne tłumaczenie co i jak zrobiłem.  Gdzie jest to a gdzie jest inne coś.  Marzy mi się ze przychodzi ktoś w zastępstwo i mówi: wypas wszystko jasne, nie musisz niczego tłumaczyć, pokazywać czy demonstrować.  Wzorce są tam gdzie są potrzebne. Albo nawet ich nie ma. Bo może aplikacja była prosta.

Ale wiecie jest najważniejsze NAZWY.  Klasy, metody, warunki, zmienne, wszystko nazywa się zgodnie z tym co ma reprezentować robić i oznaczać.  Tak bym chciał.  Tak mi się marzy.  Wiem że droga jeszcze daleka ale nie podaje się i poprawiam.  Patrzę i czytam to co napisałem i się zastanawiam czy ja to jeszcze rozumiem czy to ma sens.  Czy ktoś to zrozumie?

Zmiany w ITAN są nie uniknione! #dajsiępozać

14 thoughts on “Czytaj kod jak książkę

  1. Wiesz czasami zmienna nazywa się „x” nie po to żeby zaciemnić kod. Poprostu nazwanie zmiennej „resultOfFirstCheckAndThenReusedForResultOfThirdCheckIfResultOfSecondCheckIsEmpty” wydaje się jakieś takie …. niestosowne.
    Samo nazywanie nie pomoże :). Niestety dobre praktyki idą ze sobą w parze, albo nawet w sześciokącie (czy ile byś ich tam nie wyliczył).

    Pozdrawiam

      1. Chodziło mi o to że ja bym zrobił 2 zmienne. Ale niektórzy są na etapie mikrooptymalizacji kodu w C# (sic!). A to dość mocno kłóci się z dobrym nazywaniem zmiennych.

        Dla uściślenia – Ja wole dobre nazwy i współodczuwam twój ból który przebija się spod tego posta 🙂

      1. I tak i nie. Samo result czy IsValid może utracić sens w dalszej perspektywie. Bo: result – czego result, jaki result i inne odmiany. IsValid w jakim kontekście, dla kogo, przez kogo? To co piszesz ma sens i tak się robi i działa.
        Ja natomiast chciałbym jeszcze lepiej nazwać zmienne – i to jest trudne.

  2. Pingback: dotnetomaniak.pl
  3. MgSZłŻITkLpjBdzZCztlnscNzTrz. Moge sie zalozyc ze i tak lepiej bedzie z czytelnoscia niz teraz ??

  4. Tak na serio taka myśl mnie natchnęła że jeśli termin mocno nie goni (a goni zawsze) i wygospodarujesz chwilkę (a powinieneś ją móc wygospodarować zawsze) to jeśli dochodzimy do wniosku że potrzebujemy takiej jebundzkiej nazwy to sam osobiście zastanawiam się czy to nie miejsce dla jakiegoś superbohatera (czyt. jakiego wzorca projektowego ;-)) i czy jeśli mamy tyle warunków nie moglibyśmy ich wypchnąć do jakiejś klasy Validator tam wystawić jedną publiczną nazwę isValid walidacje zamknąć w środku (rozbić warunki, na każdy osobną metodę, okomentować) aż do momentu w którym jesteśmy w stanie metodę nazwa np isValidYear. W wystawionej metodzie zrobić koniunkcje warunków. Do czego zmierzam ano do tego że jeżeli robimy takie skomplikowane rozwiązanie które wymaga zmiennej o nazwie na 50 znaków – to może jednak zmienna jak napisałem wcześniej powinna się nazywać isValid, result czy jak tam kto chcę a logika powinna być w innej klasie.Po zerowe wszystko tak czy siak ma być komentarzem suto maszczone jak pierogi babci ;-). Podsumowując też mam ból siedziska jeśli widzę takie nazwy zmiennych 😉 bo często się zastanawiam czy taka zmienną coś mówi autorowi po kilku miesiącach czy raczej zmusza do niepotrzebnej analizy kodu. Jak ktoś to przeczytał to szacuneczek bo mnie troszkę poniosło dalekooo od tematu 😉

    1. Przeczytałem. Dziękuje. Validator może i tak – widziałem różne podejścia np. fluent validator – nie wiem czy chce, to co widziałem mówiło że mi się nie podoba. Mieliśmy walidację obiektu w obiekcie, tzn. nośnik danych wiedział o biznesie.
      jeśli chodzi o komentarze to jestem na nie. Moim zdaniem komentarze są potrzebne wtedy i tylko wtedy gdzie dzielisz przez zero i masz ku temu powód. Wszystkie inne oczywiste rzeczy powinny być oczywiste, jeśli robisz coś nie oczywistego to popraw kod, a nie rób wywodów w komentarzu. Mógłbym też napisać tutaj esej, aby komentarz był tak długi jak Twój, ale tego nie zrobię 🙂

      1. Komentarze powinny być miejscem gdzie w prostym zdaniu opisujemy co dzieje się w kodzie. Oczywiste rzeczy są tylko w oczywistych aplikacjach. Gdy robimy aplikacje medyczną, finansową czy jakąkolwiek inną bardziej skomplikowaną która już tak ‚oczywista’ nie jest to bez odpowiednich komentarzy zginiemy i żadna poprawa kodu / refaktoring tu nie pomoże…
        Komentarze nie zwalniają z myślenia, stąd dobre nazewnictwo jest również kluczowe w zrozumieniu „co autor miał na myśli”.

Dodaj komentarz