O programowaniu słów kilka

Z okazji przeprowadzania właśnie refactoringu jednego z projektów postanowiłem napisać kilka rzeczy, które gdy widzę sprawiają, że odechciewa mi się zmiany czegokolwiek.

1. Im mniej komentarzy tym lepiej.

Tak, wyznaję zasadę, która ma tyle samo zwolenników co przeciwników. Nie mniej jednak komentarz w kodzie występuje przeważnie tam, gdzie coś nie działa tak jak chciał programista i w ten sposób chce przestrzec inne osoby przed problemem, który on napotkał. Pomijam tu komentarze opisujące klasy i metody, jeśli są one wymagane do przyszłej dokumentacji, to jak najbardziej powinny być pisane, ale za pomocą ctrl + m + ctrl + o, można je bardzo prosto schować i nie są one nikomu potrzebne. Jednak jeśli kod jest dobrze napisany, czyta się go jak dobrą książkę. Jeśli czegoś szukamy patrzymy jak nazywa się funkcja i co po kolei robi. Te dwie rzeczy powinny nam starczyć, żeby zorientować się czy to czego szukamy jest gdzieś tutaj, czy może w innej części kodu.
Pozostają jeszcze przyzwyczajenia z kodu C++, czyli komentarze-szlaczki wyglądające mniej więcej tak:

///////////////////////////////////////////////////////////////////////////////////////////////////////
public void Refresh_Click(object sender, EventArgs e){
}
///////////////////////////////////////////////////////////////////////////////////////////////////////

Wiem, bo sam takie pisałem kiedy zaczynałem swoją przygodę. Jest to fajne, jeśli piszemy w notatniku i nie możemy zwinąć funkcji. Kiedy jednak mamy tak wspaniałe narzędzie jak visual studio nie musimy się bawić w oddzielanie poszczególnych funkcji, bo w tym momencie szlaczki są ważniejsze od tego co się dzieje w klasie.

2. Dziel klasy na foldery

Tak się dzieje, że kiedy zaniedbamy na samym początku podział klas na foldery, to później bardzo ciężko jest to zrobić. Im większy staje się projekt tym gorzej się połapać w tym gdzie może znajdować się dana klasa. O ile sami siedzimy w tym od początku, to programista, który dostanie nasz kod może mieć spore problemy z odnalezieniem właściwego pliku. Bardzo podoba mi się sposób w jaki programuje się w Javie, czyli podział kodu na paczki. Tam tworzymy paczki i dzielimy kod na oddzielne regiony. W C# moim zdaniem zrobione jest to trochę gorzej. Programista widząc foldery myśli, że w folderach jak to w folderach, powinien umieszczać obrazki, ikony i inne zasoby. Nie martwi się o podział klas na foldery. Tak podział daje porządek w solucji i projektach, chociaż i tak uważam że podział na paczki w Javie jest dużo fajniejszy.

3. Nie komentuj, wyrzuć

Zasada ta wydaje się szczególnie uzasadniona, kiedy korzystamy z systemu zarządzania wersjami. Często sam się łapie na tym, że komentuje kod, bo może kiedyś będę musiał do tego wrócić. Po zmianie jednak zapominamy o tych wszystkich zakomentowanych rzeczach i zostają one w projekcie. Sam widząc taki blok, jeśli nie jest on mój długo waham się czy go wywalić, czy zostawić. Przeważnie jednak wywalam. Jeśli ktoś chce wrócić do starej wersji, może przejrzeć starszego commita, a na 90% jeśli już ten blok zakomentował i zcommitował to nie wróci do starej wersji.

4. Nie bój się dodawać klas.

Zauważyłem, że wiele osób ma problemy z dodawaniem nowej klasy. Na początku oczywiście tworzymy klasy bo są nam potrzebne, ale wraz z tym jak projekt się rozrasta coraz mniej klas jest dodawanych. Wolimy dodawać nową metodę i nowe argumenty niż stworzyć nową klasę. Dochodzi czasami nawet do takich paradoksów, ze skoro mamy obiekt który przechowuje jakieś dane to w tym samym obiekcie przechowywaliśmy listę tych obiektów?! Wydaje mi się jednak, że w programowaniu obiektowym dodanie nowej funkcjonalności powinno oznaczać dodanie nowej klasy, a nie dodanie nowej metody. Tak się robiło pisząc programy strukturalne, pora się przenieść na obiekty…

5. Używaj regionów

Jedna z tych rzeczy, które sprawiają, że pisanie w C# staje się dużo wygodniejsze niż w Javie to właśnie regiony.
Tak wygląda klasa, która w rzeczywistości ma 400 lini:

6. Interfejs to fajna sprawa

Może trochę za często nawiązuje do Javy, wiem, że niektórzy ludzie nawet nie chcą słyszeć, że istnieje coś takiego, ale moim zdaniem Java ma też kilka bardzo dużych zalet i każdy programista .NET powinien poznać chociaż powierzchownie tą technologie. Jedna z rzeczy, nad którymi się często zastanawiam, to czemu w C# nie piszę interfejsów, albo jeśli piszę to wygodniej mi jest jeśli bym ich nie pisał. Nie umiem tego wytłumaczyć, wiem, że to czy używamy interfejsów, to sprawa architektury systemu. Więc technologię odsuwamy na bok, niemniej jednak pisząc w Javie miałem taki wewnętrzny przymus pisania interfejsów, natomiast pisząc w C# olewam to i piszę oddzielne klasy. Zauważyłem, że interfejsów używa niewielka ilość osób piszących w C#, natomiast znaczna większość osób piszących w Javie. Nie mam pojęcia czemu, ale interfejsy to bardzo fajna sprawa i warto ułożyć architekturę aplikacji, tak żeby jednak ich używała, ułatwi to bardzo rozszerzanie funkcjonalności.

7. Nie kopiuj, zrób funkcję

Ktoś, kiedyś, chyba na studiach powiedział mi, że jeśli programista pisze drugi raz ten sam kawałek kodu powinien się zastanowić, czy nie stworzyć nowej funkcji, a jeśli pisze go trzeci raz to już na pewno powinien ją stworzyć. Wprawdzie dziwi mnie to, że ktoś woli pisać 4 razy te same 10 linijek niż skrócić to do jednej funkcji i wywoływać ją w różnych miejscach, przecież informatycy to leniwi ludzie. Powinno nam zależeć an tym, żeby pisać jak najmniej…

Wpis ten poświęcam Panu z żółtą stroną internetową 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *