To naprawdę zależy od tego, jak skomplikowany jest kod i matematyka. Sam kod powinien - jak zawsze - być tak samo dokumentujący jak to tylko możliwe. Nazwij zmienne poprawnie, zaimplementuj metody logiczne i zwięzłe (zamiast mega-funkcji), dodaj odpowiednią dokumentację w odpowiednim miejscu (tj. Gdy nie jest oczywiste, co tak naprawdę robi kod).
Jeśli używasz nieoczywistego algorytmu, dodaj link do odwołania do źródła. Jest to rozsądna praktyka, ponieważ daje programistom bardzo szybki sposób na sprawdzenie, co robisz. Jak powiedziałem, jest to przydatne, jeśli jest to nieoczywisty, ale złożony algorytm. To powinno udowodnić, że (a) robisz coś, co ma sens, i (b) ktoś udowodnił, że to działa.
Dobrym przykładem jest praca, jaką wykonałem wokół dopasowywania tekstu rozmytego. Przeprowadziłem gruntowne badania nad algorytmami i wdrożyłem tak zwany „algorytm Smitha-Watermana” (który jest faktycznie używany do sekwencji DNA, ale ogólnie odnosi się do „dopasowania”). Zamiast więc implementować algorytm, znalazłem referencje online i zamieściłem link lub dwa. Jak wyżej, pokazuje to, że (a) mój algorytm pasuje do opublikowanego algorytmu oraz (b) algorytm został sprawdzony i wykazał, że działa.
Nie musi to jednak wyjaśniać, jak działa kod i co powinny robić różne klasy. Kiedy zaczniesz pisać „prawdziwą” dokumentację - przewodnik dla programistów dotyczący systemu - powinieneś wyjaśnić, co zrobiłeś i podać wystarczającą ilość informacji do przyszłego wsparcia. Moim zdaniem dokument ten powinien być czytelny dla osoby bez technicznej wiedzy; nie musi być „głupi”, ale powinien wykluczać żargon, a nie polegać na założonej wiedzy.