Odpowiedź na to pytanie wcale nie jest prosta, jednak pewne rozeznanie przychodzi wraz z doświadczeniem. Niezależnie od języka programowanie, framework’a, koloru skóry, wyznania ;), systemu operacyjnego etc. którego używasz poniższe rady mogą okazać się przydatne.

Autor: Grzegorz Szpetkowski

Źródło:  http://mars.iti.pk.edu.pl/~mfi/?p=320

1. Umiejętnie stosuj komentarze, no dobrze, ale co to znaczy umiejętnie ? Hm nie komentuj rzeczy oczywistych, takich, które wprost, albo bardzo łatwo wynikają z samego języka. Dobry komentarz to taki, który pozwoli innej osobie, która nie zna Twojego kodu szybko i łatwo zrozumieć jak działa, co robi i do czego służy. Nie warto jednak przesadzać w drugą stronę i komentować dla samego komentowania, trzeba wyczuć złoty środek. Interesującym pomysłem są wszelkie systemy automatycznego generowania dokumentacji (chyba najbardziej znany taki system to javadoc języka Java ze specjalnym komentarzem /**, w środowisku .NET odpowiednikiem jest komentarz ///). Na pewno każdy się zgodzi, że przejrzyściej jest odczytać interfejs publiczny klasy w javadoc’u niż czytając kod.
2. Wcięcia, w zasadzie jest to podstawa każdego porządnego kodu, mało co potrafi tak zirytować jak pomieszane ze sobą pętlę, instrukcje warunkowe bez ładu i składu, oraz (jednak w mniejszym stopniu) niekonsekwencja np. w stosowaniu klamer (ograniczników instrukcji blokowych np. w Pascal’u BEGIN i END, w C i pochodnych { }). Jeśli programujecie w większym zespole umówcie się na jeden styl i trzymajcie się go. Niektóre języki jak np. Ruby, czy Python poszły o krok dalej i same wymuszają stosowanie odpowiednich wcięć. Moim zdaniem jest to krok w dobrym kierunku, choć powinna być też możliwość wyłączenia tego mechanizmu. Można także ujednolić pewne konstrukcje językowe np. pisząc kod (X)HTML zamiast pisać „na dziko”:

   każdy przyzna, że bardziej przejrzyście jest napisać w ten sposób:

   Kod staje się zdecydowanie łatwiejszy do zrozumienia, prościej też wprowadzić w nim zmiany. Tak przy okazji nie należy nigdy stosować atrybuty language dla elementu script, jest to po prostu błędny zapis, należy stosować tylko type=”text/javascript” (dodatkowo mimo, że zawartość elementu script w tym przypadku jest pusta, nie można użyć skróconego zapisu <script type=.. />).

3. Nazwy zmiennych i klas (pójdźmy dalej: nazwy elementów i atrybutów w dokumentach XML, tabel SQL, schematów, procedur składowanych etc.). Tutaj ważne są dwie kwestie: nadawanie nazw takich nazw, które „pasują” i dobrze oddają rolę tej zmiennej (i innych). Mogę podać dobry antyprzykład zaczerpnięty z książki „Learning Perl”:
   

   Of course, choosing good or poor names makes no difference to Perl. You could name your program’s three most-important variables $OOO000OOO, $OO00OO00, and $O0O0O0O0O and Perl wouldn’t be bothered—but in that case, please, don’t ask us to maintain your code.

   Druga sprawa to styl nazywania, do oddzielenia poszczególnych części nazwy można używać np. podkreślników (_) albo stosując rożne wielkości liter (np. klasa SamochodDostawczy, metoda uruchomSilnik, proszę zauważyć, że nazwę klasy określa się rzeczownikiem, nazwę metody/funkcji/procedury przez czasownik, podobnie np. zasoby w usługach sieciowych typu REST określa się rzeczownikami, a akcje są to prostu metody protokołu HTTP np. GET, PUT). W środowisku przyjęły się pewne zwyczaje co do tej kwestii np. stałe pisany dużymi literami, Dennis Ritchie i Brian Kernighan, autorzy książki „Język ANSI C” polecają np. stosowanie krótkich nazw dla zmiennych lokalnych. Bardzo ważne, żeby w zespole programistycznym poświecić chwilę i ustalić konkretny styl.

4. Przy (niekoniecznie) skomplikowanych systemach warto stosować modelowanie. Bardzo dobrym przykładem stosowanym powszechnie są diagramy E/R dla baz danych, każdy się zgodzi, że powiązania tabel oraz same relacje są lepiej oddane w sposób graficzny, łatwiej zrozumieć „naturę” i strukturę systemu oraz wprowadzać wszelkie zmiany (np. wymagania klientów mogą ulec zmianom, system dalej się rozwija, komplikuje itp.). Podobnie w przypadków klas można pokusić się o zastosowanie notacji UML, ale ostrożnie, trzeba to robić umiejętnie, bardzo łatwo utworzyć diagram, który nie będzie do niczego przydatny. W książce „trzech amigos” czyli Panów: Grady Booch, James Rumbaugh i Ivar Jacobson „UML przewodnik użytkownika” (nawiasem pisząc zupełnie nie rozumiem dlaczego WNT usunęło link do tej książki i wielu innych ze swojej strony) zostało napisane, że diagramy UML mają służyć przede wszystkim jako pomoc w łatwiejszym zrozumieniu i „ogarnięciu” systemu właśnie przez graficzny model, a nie jako cel sam w sobie. Zachęcam to zajrzenia na blog Pana Michała Wolskiego, który się zajmuje tym bardziej szczegółowo.
5. Tam gdzie tylko się da stosujcie bibliotekę standardową danego języka. Dzięki temu wszyscy upraszczamy sobie życie, łatwiej jest się porozumieć, oraz zmniejszają się problemy z instalacją (inną bibliotekę trzeba skądś pobrać i w jakiś sposób dodać). Jest też większa niż szansa, że osoba programują w C# będzie znała klasę XmlReader do odczytu XML, aniżeli jakąś zewnętrzną, mniej popularną. Oczywiście nie mówię, że w ogóle należy pomijać zewnętrzne biblioteki, czasem jest to konieczność (bo są lepszej jakości, oferują funkcjonalność, której brakuje), ale zalecam ich rozważne i oszczędne dobieranie.
6. Moim zdaniem należy dbać o to żeby kod był krótki (ale nie kosztem przejrzystości), między inni dlatego w punkcie 5. nakładam taki nacisk na umiejętne korzystanie z bibliotek, a nie wymyślanie koła na nowo. Przykładowo jeśli STL w C++ zawiera algorytm do sortowania i o ile spełnia on wymogi jakościowe, to znacznie lepiej użyć te dwie linijki kodu. Jakie daje to korzyści: przyspieszenie pracy, mniej błędów, elastyczność, łatwość modyfikacji, krótki czas „wejścia” nowego programisty. Uważam, że oprócz samego języka programowania dzisiaj coraz bardziej liczy się to, czy posiada bogatą bazę bibliotek.
7. Używanie odpowiedniego IDE, takiego które zauważalnie przyspiesza pracę, czyni ją bardziej efektywną. To nie tylko wygoda, ale przede wszystkim oszczędność czasu, lepsza organizacja pracy i znacznie mniejsza szansa na popełnienie pomyłki. Na pewno każdy kto, używał chociaż raz auto-uzupełniania kodu (nie wspominając o kolorowaniu składni) zgodzi się, że jest to lepszy sposób niż szukanie po dokumentacji, której wersji przeciążanej/przeładowanej metody mogę użyć, a zaraz jak dokładnie się ona nazywała ? IDE załatwia to za nas, potrafi też więcej (np. Eclipse automatycznie wygeneruje getter’y setter’y dla zadanych właściwości), co więcej integruje w sobie obsługę systemu kontroli wersji (np. Apache Subversion, Git), kolejnego narzędzia przydatnego w programowaniu w zespole i wielu innych narzędzi przez wtyczki (np. HTTP4e do Eclipse pozwala wykonywać dowolne żądania HTTP wraz z obsługą autoryzacji i przeglądać odpowiedzi serwera, innty przykład to integracja z modelowaniem UML w Visual Paradigm for UML, z tego ostatniego korzysta m.in. NASA oraz Intel). Warto poświęcić czas na naukę korzystania z wybranego zintegrowanego środowiska programistycznego, dzięki temu będziesz bardziej produktywny, a programowanie stanie się przyjemnością.
8. Moim zdaniem nie warto przesadzać z wykorzystywaniem własności priorytetów operatorów, kod powinien być raczej czytelny dla człowieka bez dłuższego spędzania czasu na tabelką priorytetów, tam gdzie są sytuacje niejasne lepiej użyć nawiasów. Nie chodzi tutaj tylko o lenistwo, kod, w który sposób złożony wykorzystuje priorytety jest bardziej podatny na błędy i trudniej w nim wprowadzać zmiany. W sytuacjach oczywistych nie trzeba nawiasów, przykładowo uroczy kod z języka znacznikowego XML (ang. XML markup language) XSLT (transformacje XML):

9. Do danego zadania należy stosować odpowiedni język, przykładowo tirem nie przejedziemy przez wąskie uliczki Paryża, podobnież jak w Perl’u nie będziemy pisać sterowników, ani gier, tylko raczej przetwarzanie tekstu. Na końcowy akcent cytat ponownie z książki „Learning Perl”:
   

   In a perfect world, every programmer could know every language; you’d always be able to choose the best language for each project.

Bardzo dobrym uzupełnieniem tego tematu może być książka „Czysty kod. Podręcznik dobrego programisty”. Wprawdzie jeszcze nie czytałem (a mam taki zamiar), ale patrząc na jej opinie jestem przekonany, że jest znakomita i jak najbardziej warta przeczytania.