Dobre praktyki w pisaniu kodu MATLAB? [zamknięte]

Przeczytaj Kod kompletny , zrobi cuda na wszystko. Pokaże ci gdzie, jak i kiedy sprawy mają znaczenie. To właściwie Biblia rozwoju oprogramowania (IMHO.)

MATLAB Programming Style Guidelines autorstwa Richarda Johnsona jest dobrym źródłem informacji.

Cóż, jeśli chcesz to w kategoriach laika:

Polecam ludziom napisać najkrótszy czytelny program, który działa .

Jest o wiele więcej zasad formatowania kodu, nazw zmiennych, klas projektowych, oddzielnych obowiązków. Ale nie należy zapominać, że wszystkie te zasady są tylko po to, aby upewnić się, że Twój kod jest łatwy do sprawdzenia pod kątem błędów i aby upewnić się, że jest możliwy do utrzymania przez kogoś innego niż oryginalny autor. Jeśli zachowaj powyższą rekomendację w Twój progam będzie taki.

Ta lista może trwać długo, ale niektóre ważniejsze rzeczy to:

• tiret.
• opisowe nazwy zmiennych.
• opisowe nazwy klas / funkcji.
Nie powielaj kodu. Jeśli wymaga duplikacji umieść w klasie / funkcji.
• Użyj gettors / settors.
Wyeksponuj tylko to, co jest niezbędne w Twoich obiektach.
• zasada pojedynczej zależności.
• Naucz się pisać dobre komentarze, a nie dużo komentarzy.
• Bądź dumny ze swojego kod!

Dwa dobre miejsca na początek:

Clean-Code Handbook

Code-Complete

Jeśli chcesz użyć czegoś jako odniesienia lub etykiety, często stosuję oficjalne konwencje stylu Google dla dowolnego języka, w którym pracuję, na przykład dla C++ lub dla Python.

The Practice of Programming autorstwa Roba Pike ' a i Briana W. Kernighan ma również sekcję dotyczącą stylu, która okazała się pomocna.

Po pierwsze, "kody" nie jest właściwym słowem. Kod jest reprezentacją innej rzeczy, zwykle numerycznej. Poprawne słowa To "kod źródłowy", a liczba mnoga kodu źródłowego to kod źródłowy.

--

Pisanie dobrego kodu źródłowego:

1. Skomentuj kod.
2. używaj nazw zmiennych dłuższych niż kilka liter. Między 5 a 20 to dobra zasada.
3. krótsze linie kodu nie są lepsze-używaj białych znaków.
4. bycie "sprytnym" z Twoim kodem to dobry sposób, aby później zmylić siebie lub inną osobę.
5. rozłożyć problem na jego składniki i użyć hierarchicznego projektu do złożenia rozwiązania.
6. pamiętaj, że będziesz musiał zmienić swój program później.
7. Skomentuj kod.

Bardzo trywialny przykład zbyt skondensowanego kodu z czubka mojej głowy

for(int i=0,j=i; i<10 && j!=100;i++){
     if i==j return i*j; 
     else j*=2;
}}

Choć jest to bardziej czytelne:

int j = 0;
for(int i = 0; i < 10; i++)
{
   if i == j 
   {
      return i * j;
   }
   else
   { 
     j *= 2;
     if(j == 100)
     {
        break;
     }
   }
}

Drugi przykład ma logikę wyjścia z pętli wyraźnie widoczną; pierwszy przykład ma logikę splątany z przepływem sterowania. Zauważ, że te dwa programy robią dokładnie to samo. mój styl programowania zajmuje wiele linii kodu, ale nigdy nie spotkałem się z zarzutem, że trudno jest go zrozumieć stylistycznie, podczas gdy bardziej skondensowane podejścia są dla mnie frustrujące.

Doświadczony programista może i przeczyta oba-powyższe może sprawić, że na chwilę się zatrzyma i zastanowi się, co się dzieje. Zmuszanie czytelnika do siadania i wpatrywania się w kod jest to nie jest dobry pomysł. Kod musi być oczywisty. Każdy problem ma wewnętrzną złożoność wyrażania swojego rozwiązania. Kod nie powinien być bardziej złożony niż złożoność rozwiązania, jeśli w ogóle jest to możliwe .

To jest istota tego, co inny plakat próbował przekazać - nie rób programu dłużej,niż trzeba. Longer ma dwa znaczenia: więcej linii kodu (tj. umieszczenie szelek na własnej linii) i bardziej złożone. Tworzenie programu bardziej skomplikowanego niż trzeba nie jest dobre. Making it more czytelny jest dobry.

Zobacz 97 Rzeczy, Które Każdy Programista Powinien Wiedzieć .
Jest darmowy i zawiera wiele klejnotów takich jak ten:

Jest jeden cytat, który moim zdaniem jest szczególnie dobre dla wszystkich programów deweloperzy poznają i trzymają się blisko ich serca:

Piękno stylu i harmonii i wdzięku a dobry rytm zależy od prostoty. - Platon

W jednym zdaniu myślę, że to podsumowuje wartości, które my jako oprogramowanie deweloperzy powinni aspire to.

Jest wiele rzeczy, do których dążymy w naszym kodzie:

• czytelność
• Konserwacja
• szybkość rozwoju
Nieuchwytna jakość piękna]}

Platon mówi nam, że czynnikiem wszystkich tych cech jest prostota.

Przewodnik Python Style Guide jest zawsze dobrym punktem wyjścia!

Europejskie standardy pisania i dokumentowania wymiennego kodu Fortran 90 były w moich zakładkach od zawsze. Ponadto, był tu wątek, ponieważ jesteś zainteresowany MATLAB, na organizowanie kodu MATLAB.

Osobiście odkryłem, że nauczyłem się więcej o stylu programowania z pracy przez SICP, który jest Intro MIT do tekstu Comp SCI (jestem około ćwierć drogi przez.) Niż jakakolwiek inna książka. Mając to na uwadze, jeśli zamierzasz pracować w Pythonie, Przewodnik po stylu Google to doskonałe miejsce na początek.

Czytałem gdzieś, że większość programów (skryptów) nigdy nie powinna być dłuższa niż kilka linijek. Wszystkie wymagane funkcje powinny być wyodrębnione w funkcje albo klas. Zgadzam się.

Wiele dobrych punktów zostało poczynionych powyżej. Zdecydowanie popieram wszystkie powyższe. Chciałbym również dodać, że pisownia i konsekwencja w kodowaniu to coś, co ćwiczysz (a także w prawdziwym życiu).

Pracowałem z kilkoma zespołami offshore i chociaż ich angielski jest całkiem dobry, ich błędy ortograficzne spowodowały wiele zamieszania. Tak na przykład, jeśli trzeba szukać jakiejś funkcji (np getFeedsFromDatabase) i przeliterować bazy danych źle lub coś innego, które mogą być duże lub mały ból głowy, w zależności od tego, ile zależności masz na tej konkretnej funkcji. Fakt, że jest powtarzany w kółko w kodzie, po pierwsze, doprowadza cię do szaleństwa, a po drugie, utrudnia analizę.

Nadążaj także za spójnością w nazewnictwie zmiennych i funkcji. Istnieje wiele protokołów do przejścia, ale tak długo, jak jesteś konsekwentny w tym, co robisz, inni, z którymi pracujesz, będą mogli lepiej czytać twój kod i być za to wdzięczni.

Prawie wszystko tu powiedziane, i coś więcej. Moim zdaniem najlepsza strona dotycząca tego ,czego szukasz (szczególnie zen części Pythona są zabawne i prawdziwe)

Http://python.net / ~goodger/projects/pycon/2007/idiomatic/handout.html

Rozmowy o PEP-20 i PEP-8, trochę pisanek (fajnych rzeczy) itp...

Możesz rzucić okiem na kurs Stanford online: Metodologia programowania CS106A. Instruktor dał kilka naprawdę dobrych instrukcji do pisania kodu źródłowego.

Niektóre z nich są następujące:

1. Pisz programy dla ludzi do czytania, nie tylko dla komputerów do czytania. Oba muszą być w stanie go odczytać, ale o wiele ważniejsze jest, aby osoba go odczytała i zrozumiała, a komputer nadal wykonuje go poprawnie. Ale to pierwszy główne zasady inżynierii oprogramowania do pomyśl o tym.

2. Jak dodawać komentarze:  umieść w komentarzach, aby wyjaśnić rzeczy w programie, które nie są oczywiste

3. Jak zrobić rozkład

   1. jedna metoda rozwiązuje jeden problem
   2. każda metoda ma kod przybliżony 1~15 linii
   3. podaj dobre nazwy metod
   4. Zostaw komentarz do kodu

Testy Jednostkowe
Python i matlab są językami dynamicznymi. Wraz ze wzrostem bazy kodu będziesz zmuszony do refaktoryzacji kodu. W przeciwieństwie do języków typowanych statycznie, kompilator nie wykryje 'uszkodzonych' części w Twoim projekcie. Korzystanie z frameworków testów jednostkowych, takich jak xUnit nie tylko kompensuje brakujące kontrole kompilatora, ale pozwala na refaktoryzację z ciągłą weryfikacją dla wszystkich części projektu.

Source Control
Śledzenie kodu źródłowego za pomocą system kontroli wersji jak svn, git lub jakiekolwiek inne pochodne. Będziesz w stanie przewijać się w historii kodu, tworzyć gałęzie lub tworzyć tagi dla wdrożonych / wydanych wersji.

Śledzenie Błędów
Użyj systemu śledzenia błędów, jeśli to możliwe, połączonego z systemem kontroli źródła, aby być na bieżąco ze swoimi problemami. Możesz nie być w stanie lub nie być zmuszony do natychmiastowego rozwiązania problemów.

Reduce Entropy
Podczas integracji nowych funkcji w twoja istniejąca baza kodu, dodasz więcej linii kodu i potencjalnie większą złożoność. To zwiększy entropię. Staraj się utrzymać swój projekt w czystości, wprowadzając interfejs lub hierarchię dziedziczenia w celu ponownego zmniejszenia entropii. Nie zwracanie uwagi na entropię kodu sprawi, że Twój kod będzie niemożliwy do utrzymania w czasie.

Wszystkie wyżej wymienione
Czyste tematy związane z kodowaniem, takie jak używanie przewodnika po stylach, a nie powielanie kodu ..., już wspomniano.

Mały dodatek do wspaniałych odpowiedzi już tutaj dotyczących Matlab:

• Unikaj długich skryptów, zamiast tego pisz funkcje (podprogramy) w oddzielnych plikach. Dzięki temu kod będzie bardziej czytelny i łatwiejszy do optymalizacji.

• Użyj wbudowanych funkcji Matlab. Oznacza to, że dowiedz się o wielu wielu funkcjach, które oferuje Matlab, zamiast wymyślać koło na nowo.

• Użyj sekcji kodu , i niezależnie od drugiego kodu struktura najnowsza wersja Matlab oferuje.

• Dowiedz się, jak porównać swój kod za pomocą timeit i profile . Przekonasz się, że czasami pętle For są lepszym rozwiązaniem.

Najlepsza rada, jaką otrzymałem, gdy zadałem to pytanie, była następująca:

Never code while drunk.

Uczyń go czytelnym, uczyń intuicyjnym, uczyń zrozumiałym i skomentuj.