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
<font size="4">Dobrych programów.</span>