Poniższe zalecenia nie są moim wymysłem (zob. np. propozycja konwecji Stata, z której conieco zaczerpnąłem). Podobnie jak w matematyce czy ekonometrii używamy pewnej konwencji (np. macierze oznaczamy podgrubionym symbolem z wielkiej litetery, subskrypt t najczęściej oznacza indeks obserwacji po czasie, itp.), tak w programach jednolita notacja poprawia czytelność. Ja i moi współpracownicy wiemy, że nauka kilku z poniższych reguł była bolesna (czytaj: na własnych błędach). Przyjęcie tych zasad na początku nauki Stata oszczędzi sporo czasu i nerwów przy pisaniu projektu i ogólnie dalszej pracy z danymi (zwłaszcza, że większość zasad może być zastosowana do innych pakietów statystycznych lub nawet języków programowania).


  1. Używaj skryptów (do-file). Wszelkie operacje na danych powinny byc w kodzie, a nie recznie. Dzieki temu kod zaczytuje dane zrodlowe i istnieje mozliwosc cofniecia przeksztalcen danych. Zadbaj o to, żeby Twój do-file był samodzielny, tzn. zaczytywał dane, wykonywał obliczenia i raportował wyniki bez potrzeby uruchamiania innych skryptów.

  2. Stosuj logiczne nazwy zmiennych. Powinny zaczynać się z wielkich liter, np. KodPocztowy albo PostCode. Dopuszcza się też oddzielanie wyrazow przy użyciu symbolu "_" - np. Kod_Pocztowy. Nazwy identyczne z nazwami komend lub zaczynające się od "_" mogą powodować błędy.

  3. Używaj pełnych nazw komend (tym bardziej dotyczy to skracania zmiennych - bardzo łatwo o pomyłkę). Skróty sa dobre gdy chcemy szybko coś przeliczyć w terminalu, ale w do-file nie musimy oszczędzać liter.
  4. ŹLE:
    reg y x
    su x

    DOBRZE:
    regress y x
    summarize x

  5. Formuly matematyczne: operatory oddzielamy spacją. Np.
  6. ŹLE:
    ZmienneLogMnozony100=log(Zmienna1+Zmienna2)*100

    DOBRZE:
    ZmienneLogMnozony100 = log(Zmienna1 + Zmienna2) * 100
    ZmienneLogMnozony100 = log( Zmienna1 + Zmienna2 ) * 100

  7. Stosowanie wcięcia także poprawia czytelność kodu. Wcięcia powinny być używane do oddzielania poziomów w pętli. Np.
  8. ŹLE:
    foreach ii of varlist var_* {
    gen kwadrat_`ii' = `ii' * `ii'
    }

    DOBRZE:
    foreach ii of varlist var_* {
    gen kwadrat_`ii' = `ii' * `ii'
    }

  9. Stosuj tabulację do podziału komend jednowierszowych na bloki. Np.
  10. ŹLE:
    logit zmienna1 x1 x2 x4
    logit z2 x1 x3 x4

    DOBRZE:
    logit zmienna1 x1 x2 x4
    logit z2 x1 x3 x4

  11. Stosuj ii (podwójne i) jako nazwę iteratora w pętli (zob. przykład wyżej). Do iteratorów w pętlach głębszych poziomów odpowiednio: jj, kk, itd. Nie używaj podwójnego i, j, itd. w nazwach innych zmiennych, dzięki czemu łatwo znajdziesz iteratory w kodzie.

  12. Na końcu kodu dodaj 2-3 puste linie. Dzięki temu łatwo zauważysz gdzie kończy się kod -- nie przeoczysz ostatniej linii kodu.

  13. Uzywamy komentarzy w kodzie. W przeciwnym wypadku kod nie jest czytelny dla innych a po pewnych czasie przestaje być czytelny nawet dla samego autora kodu.

  14. Nie zaleca się używania do komentarzy pojedynczego symbolu "*". Zamiast tego do jednolinijkowych komentarzy nalezy uzywac "//".

  15. Używaj logu. Dzięki temu łatwiej wychwycisz błędy i porównasz wyniki.

  16. Automatyzuj raportowania wyników. W Stata jest wiele komend pozwalających automatycznie generować wykresy i tabele, niemal w każdym formacie (tabele np. w: Word, TeX, HTML czy XML).


  17. Dodatkowe zalecenia dla dużych projektów (do takich zawsze zaliczam pracę w zespole, niezależnie od tego jak "duży" jest kod):


    -- "Parametry wejściowe" komend zamiast ręcznego wpisywania (minimalizuje to ryzyko błędu, np. gdy zmienimy "parametr wejsciowy" w jednym miejscu, a zapomnimy w innym).
    -- W przypadku dużych projektów (wiele obliczeń, kilka osób obsługuje projekt) - stosuj ścieżki względne z logiczną strukturą podkatalogów. W rezultacie zmiana ścieżki (np. po przeniesieniu projektu na pendrive lub inny komputer) wymagać będzie modyfikacji jednej linii skryptu.