Programowanie w języku C#

Jak pisać dobre programy

  • 3 komentarze
  • 1832 odsłony
  • Oceń ten tekst jako pierwszy

Wstęp


Zagadnienie jak w temacie, w rzeczywistości niezwykle obszerne. Postaram się tutaj odpowiedzieć na zadane pytanie, oraz przedstawić parę wartych zapamiętania uwag.


No więc jak?


Gdy piszesz z kimś



Wymagania


Pierwszym krokiem jest stworzenie listy zagadnień jakie chcemy umieścić w ostatecznej wersji. Ważne jest by były dość ogólne (nie ograniczały naszej swobody), lecz też wystarczająco szczegółowe (byśmy wiedzieli co mamy robić...). Stworzenie dobrych wymagań to spory krok w kierunku stworzenia dobrej aplikacji.
"Program do obliczania średniej statystycznej, mediany, sumy i wariancji danego zestawu danych oraz normalizacji ich do przedziału 0..1" daję komplet potrzebnych informacji, zaś problem "Programu do obliczania statystyk" jest dość mętny.

Topografia kodu


Warto też ustalić i konsekwentnie wprowadzać podział i przypisanie zadań. Zastanów się w jaki sposób chcesz podzielić kod na klasy i moduły.

Podział kompetencji


Zanim rozpoczniemy pracę nad większym projektem należałoby podzielić się na mniejsze zespoły pracujące nad konkretnymi częściami (klasami) kodu. Nie ma nic gorszego niż "współpraca", gdzie pierwszy programista tworzy klasę, drugi poprawia go bez konsultacji z nim, po jakimś czasie do kodu patrzy trzeci i dochodzi do wniosku że nazwy zmiennych nie mają sensu i je zmienia (też bez konsultacji) i to w czasie gdy pierwszy pisze klasę dziedziczącą po pierwszej wersji która nijak nie będzie działała na "poprawionej" wersji. Podział kompetencji po prostu.

Czytelność



Na pierwszym etapie jest to chyba najważniejsze. Pisanie o dokumentacji czy topografii w przypadku pisania prostego programu (np. własnej wersji notatnika) nie ma wielkiego sensu, a pisać czytelnie trzeba zawsze. Jeśli zbagatelizujemy ten problem może się okazać że gdy wrócimy po roku do napisanego dzieła (żeby np. coś poprawić) okaże się że nie rozumiemy co "dzieło" właściwie robi...

Stałe


Używaj stałych (to szczególnie do początkujących którzy zaczynają pisać coś poważnego), to naprawdę nic nie kosztuje a wielokrotnie zwiększa czytelność, naturalność i odporność na błędy programu.
Przykład chyba zbędny.

Zmienne


Przede wszystkim ich nazwy. Zmienna przechowująca nazwisko jakiejś postaci (np. użytkownika) powinna nazywać się "Nazwisko" a nie na przykład "x" (nic nie mówi) czy "Stan_Cywilny" (wprowadza w błąd!).
Ważne też, przy programowaniu obiektowym, jest odpowiednie ustawienie uprawnień - publiczne powinny być tylko te zmienne przy których jest to absolutnie konieczne.

Komentarze


Kod należy komentować, głównie po to żeby uniknąć sytuacji jak w punkcie "czytelność" - zamiast godzinami zastanawiać się co poeta miał na myśli wystarczy wysilić palce przez parę sekund...


Idiomy


W każdym języku występują zwyczajowe konstrukcje, również zwiększają czytelność.

for (int i = 1; i < 10; i++)


Jeśli nie masz jakiegoś naprrrawdę ważnego powodu w instrukcji for używaj i (albo j, k, l...).

Konsekwencja


Warto podczas programowania trzymać się jednej konwencji. Przykład takich niekonsekwencji?

string Imię_osoby_numer_jeden = "Adam";
string NazwiskoOsobyNumerJeden = "Mickiewicz";


Najlepiej używać jednego sposobu zapisu nazw zmiennych, tzn Rozdzielać_kolejne_wyrazy_znakiem_podkreślenia albo PierwsząLiteręKażdegoWyrazuPisaćWiększą. (Jeśli program pisze wiele osób niech wszyscy stosują się do jednej konwencji).

Jest jeszcze jedna czasem praktykowana konwencja, znaczy zaczynanie nazw zmiennych lokalnych (prywatnych) z małej, a globalnych (publicznych) z dużej litery.

Dokumentacja


Program trzeba też na bieżąco dokumentować. Dokumentację dzielimy na:
Projektową - tworzoną podczas pisania programu - głównie opisy poszczególnych elementów, funkcji.
Testową - co się dzieje podczas uruchamiania programu?
Użytkową - dla (ewentualnych) użytkowników - czyli przeróżne podręczniki.

Co jeszcze w C#



Jako że ten artykuł piszę głównie pod C# (chociaż kiedy piszesz w innym języku również możesz skorzystać - większość rad jest uniwersalna), więc wymienię jeszcze parę udogodnień "pod C#":

Summary


Pozwala umieścić opis funkcji (zmiennej też) w kodzie w ten sposób, że programista pisząc widzi czego program od niego oczekuje:

przykład z forum:
 
/// <summary>
/// Konstruktor obiektu obsługującego DirectX
/// </summary>
/// <param name="parent">Okno, które będzie celem renderowania grafiki</param>
/// <param name="windowed">Czy renderować w oknie (true) czy pełnoekranowo (false)?</param>


Regiony


Pozwalają usunąć z pola widzenia niepotrzebna nam części kodu. Ja z przyzwyczajenia zazwyczaj dzielę klasy na 4 regiony: "zmienne", "inicjalizacyjny", "prywatny" i "publiczny". W publicznym wszystko do czego można się dostać z zewnątrz, w prywatnym przeciwnie, inicjalizacyjny komentarza nie wymaga a w "zmiennych" zapisuję deklarację co ważniejszych zmiennych.

Przypominam że w C# regiony zapisuje się według następującej konstrukcji:
#region Tutaj_nazwa_regionu
// w regionie...
#endregion



Koniec


I to już tyle. Mam nadzieję że te pare porad pomoże zaczynającym z programowaniem w pisaniu
Dobrych programów.

3 komentarze

msm 2009-06-18 13:56

Co do pierwszego to masz rację, poprawię to jak znajdę czas.
Co do drugiego... Ten kto zaprezentuje mi poważny projekt (czyli nie jakiś hello world czy coś) który został napisany "na odwal się" niech pierwszy rzuci kamieniem. I jeszcze jedno -> pisząc podrozdział "topografia kodu" miałem na myśli to o czym mówi MVC. Co z tego że ma on jedną linijkę ;)
I ostatnia twoja uwaga -> podczas pisania wyglądało to inaczej, ale Foo_Bar i FooBar były jakieś nieczytelne...

Deti 2009-06-17 17:09

Kilka uwag:

- w C# nie ma czegoś takiego jak zmienna publiczna/prywatna. Są zmienne, pola, właściwości - a są to kompletnie różne rzeczy. Zmienne w ogóle nie mają modyfikatorów dostępu. Należałoby to poprawić.

- artykuł opisuje raczej " jak pisać czytelny kod",a nie jak pisać dobre programy - od tego są zasady programowania obiektowego (zobacz: S.O.L.I.D principles, design patterns, MVC i tak dalej)

- "NazwiskoOsobyNumerJeden" - sam pomysł na numerację zmiennych w taki sposób jest gorszący, .. a w tym przypadku konwencja/wielkość liter jest już nieważna

msm 2009-06-17 12:54

Widzę że zrobiłem duży błąd - artykuł chciałem nazwać oczywiście Jak pisać dobre programy w C#. Bez tego niektóre fragmenty nie mają sensu :/