Polecam

.NET Blogs PL
CodeGuru


Jak nie powinno się pisać programów

October 17, 2009 in categories: pro by Gutek

11

Nie spodziewajcie się długiego postu, krótko i na temat. Ostatnio w moje ręce wpadł projekt, którego jak kod zobaczyłem to nap oczątku złapałem się za głowę a potem przez pół dnia się z niego śmiałem. Nawet nie chodzi o to, że design był zły, choć do najlepszych on nie należy ale ten temat pominę. Chodzi raczej o nazewnictwo użyte w projekcie.

Odkąd sięgam pamięcią zawsze byłem uczony i sam się uczyłem iż przy tworzeniu projektu korzysta się z unifikowanego nazewnictwa - to znaczy, jak raz podejmę decyzję na temat użycia słowa Get i Set przy właściwościach to będę z niego korzystał cały czas a nie raz robił Retrive a raz Get, raz Update a raz Set. Także jak raz użyłem CAML to będę z niego korzystał. To znaczy istnieją zasady przejrzystego pisania kodu. MS nawet udostępnia narzędzie, które was w tym może wesprzeć – StyleCop. Do tych reguł także zaliczam użycie pewnego języka. Jeżeli piszę Set to nie użyje Ustaw, tak naprawdę nigdy nie użyje Ustaw ale spotkałem się z projektami, gdzie klient wymagał polskiego nazewnictwa klas i metod (sic!). No dobrze, ale do czego zmierzam? Mianowicie do tego fragmentu kodu:

private void DetailsUprawnieniaUprawnienieChanged(object sender, SelectedElementEventArgs e) 
{
	DetailsRole.Visible = false;
	DetailsUprawnienia.Visible = false;

	((RoleFilterAndSelection) FiltrIWybor).UpdateListBoxes(e.Typ, e.Kod); 
}

Przyjrzyjmy się temu uważniej:

  • Nazwa metody: Details Uprawnienia Uprawnienie Changed - sorki, ale co oznacza UprawnieniaUprawnienie oraz co ono ma wspólnego ze słowem Details?
  • Nazwa zmiennych: Details Role, Details Uprawnienia - tak, nie mylicie się, Role to polskie słowo :)
  • Nazwa klasy: Filtr i Wybor - to już był cios poniżej pasa, myślałem, że to jakiś interfejs czy coś, ale okazało się, że to naprawdę oznacza Filtr i Wybór (sic!)

Aby było tego mało, wyobraźcie sobie solution, które składa się z 15 projektów, każdy projekt ma od kilkunastu do kilkudziesięciu klas i każda jest tak pisana. Polska nazwa klasy a w środku metoda FindAll, albo GetRulesByNazwaUzytkownika, albo na odwrót, angielska nazwa klasy a metody po polsku. Takiego miszmaszu nie widziałem od 2 roku studiów kiedy to przypadkowo spojrzałem na monitor znajomego. I widziałem to tylko raz. Nie wiem jak dla was ale dla mnie to jest jak wejście na wysypisko śmieci. Wierzę, że wy czegoś takiego nie popełniacie, jeżeli popełniacie, to proszę poprawcie to lub w kolejnych projektach użyjcie już z unifikowanego nazewnictwa. No chyba, że waszym celem jest zrobienie własnego obfuscatora :)

A teraz pytanie do was, czy spotkaliście się kiedyś z podobnym kodem? Co wtedy zrobiliście, mogliście wpłynąć na to by już tak nie wyglądał? Ja osobiście nie wiem co mam zrobić, a wiem, że będę musiał coś do niego dopisać i wiem, że z powodu nazw klas i ich metod nie będę wstanie wprowadzić rozsądnego, poprawnego nazewnictwa.




 

 

 

10 comments for "Jak nie powinno się pisać programów"

  1. mj
    mj Says:

    Uśmiałem się do łez Smile. Pomieszanie spotykałem, ale głównie w krótkich (tysiąc, dwa tysiące linii kodu) skryptach powłoki - wtedy machałem ręką i szedłem robić swoje. Jak było bardzo źle, robiłem "review" kodu i wysyłałem zainteresowanym, wtedy istniała szansa, że nie popełnią tego drugi raz.

    Jeżeli jest to tak duże jak piszesz - to jest to studnia bez dna Frown, która musi sie skończyć katastrofą. Zatem zalecam szczyptę czarnego humoru, na każdy dzień i książkę "Marsz ku klęsce. Poradnik dla projektanta systemów".

  2. andrzej
    andrzej Says:

    Spodziewałem się czegoś bardziej dramatycznego ;) Może dlatego, że sam pisałem kilka modułów w podobnym projekcie. Geneza powstania trochę go broni - klasy były automatycznie generowane na podstawie bazy danych (z polskim nazewnictwem - tak przejęta była od klienta) i kwiatki pod tytułem GetFakturiesList były czymś "normalnym". Ciekawe, czy w Twoim projekcie również był to wynik zapuszczenia automatu, czy ktoś miał tyle fantazji... Bo jeśli to drugie - faktycznie śmiech ;)

    • Gutek
      Gutek Says:

      Z tego co sie dowiedizalem, to jest to praca kilku zespolow, z ktorych kazdy stary juz nie pracuje w danej firmie. Dodatkowo aplikacja byla pisana w VB 3 (to sa dopiero stare czasy) a dopiero nie dawno przypisana na .NET.

  3. n0rr3c
    n0rr3c Says:

    Witam.

    Ostatnio mialem "przyjemnosc" przegladnac prosta aplikacje, dzieki ktorej pewna osoba uzyskala stanowisko programisty i pracowala na nim przez ponad rok. Aplikacja ta nie dosc ze zawierala zapytania SQL bezposrednio w formularzach WinForms to jeszcze wszystkie nazwy byly po polsku i co najgorsze - zawieraly polskie litery!
    Chcialbym jeszcze nadmienic, ze ta osoba skonczyla studia informatyczne na specjalnosci Inzynieria Oprogramowania...

    Pozdrawiam.

    • andrzej
      andrzej Says:

      Dobrze, że to są jednostkowe przypadki. Przytoczony przez Ciebie w artykule (nie komentarzu) przykład zawierał chociaż sensowną "architekturę"? Bo to o czym ja pisałem poprzednio poza nazewnictwem było nawet w porządku.

      Ja, po książce, którą obecnie czytam ( andrzej.net.pl/.../ ), może skuszę się na: www.amazon.com/.../0132350882.

      • andrzej
        andrzej Says:

        oj zamieszałem coś - pytanie było do autora artykułu, nie komentarza ;)

        • Gutek
          Gutek Says:

          @n0rr3c

          Smile hehe

          @andrzej

          tak, z tego co zauwazylem to sa zalazki dobrej architektury. Problem polega na tym ze nie wiem czy to jest praca aktualna czy praca w momencie przepisywania systemu na .NET. ogolnie wiem co chcieli osiagnac, ale cos po drodze poszlo nie tak i teraz znow chca to samo osiagnac co przedtem Smile

        • Gutek
          Gutek Says:

          oj z arch sie naprawde pomylilem. na pierwszy rzut oka naprawde niezle wygladalo, ale to co po 2 dniach pracy nad projektem moge powiedziec ze to jest bagno. operacje na kolekcjach na instancji obiektu (na przyklad: item.GetAllItems()). jeden buisness object to 3 klasy, 2 interfejsy. Jeden obiekt to wrapper na drugi obiekt (sic!) dokladnie mowiac na entities zostala zbudowana warstwa business object, ktora zawiera te same metody co entities, te same poperty co entities plus jakies dodatkowe pomniejsze metody (choc to chyba zadki przypadek z tego co widzialem), te dodatkowe to do tej pory byly ToString (wow) i CompareTo.

          Gutek

  4. Bartosz
    Bartosz Says:

    Witam, a ja chciałbym się podzielić swoimi uwagami. Jako programista działam 4 lata w warunkach produkcyjnych. Realizowałem różne projekty i wydaje mi się, że kod powinien być pisany w takim języku w jakim dogadujemy się z klientem (przynajmniej część biznesowa). Szczególne znaczenie ma to kiedy realizujemy projekt dla jakiejś specyficznej działalności. Po co tracić czas na wymyślanie angielskich odpowiedników dla polskich określeń, co niekiedy jest niemożliwe i zaciemnia obraz. I tak samo jest w drugą stronę czyli jeśli mamy klienta zagranicznego, z którym dogadujemy się po angielsku i on w tym języku opisuje czego potrzebuje to bez celowe jest tłumaczenie tego na polski. Najchętniej wszędzie stosowałbym angielski ale trzeba to ważyć między ładnie wyglądającym kodem, a łatwością w zrozumieniu tego co ktoś napisał.
    Jeśli chodzi o część architektury aplikacji to faktycznie wolę używać angielskich nazw ale absolutnie nie jestem zwolennikiem mieszania języków w obrębie klas, czy nazw metod.

1 trackbacks or pingbacks for "Jak nie powinno się pisać programów"

Comments are closed

© 2008-2010 Jakub Gutkowski. Powered by BlogEngine.NET 1.5.1.14. Hosted on OrcsWeb.

Design