Czy funkcje „matematyczne” powinny być zgodne z notacją matematyczną?

Przypuszczam, że to pytanie zostanie natychmiast oznaczone jako subiektywne, ale które według Ciebie jest lepsze:

double volume(double pressure, double n_moles, double temperature) {
  return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

lub

double volume(double P, double n, double T) {
  return n*R*T/P;
}

Innymi słowy, czy funkcje implementujące pewne równanie powinny być zgodne z notacją tego równania, czy też powinny używać bardziej szczegółowych nazw?

Zależy, kto to czyta. Jeśli możesz zagwarantować, że przez całą wieczność, następny programista, który czyta twój kod, jest również zaznajomiony z termodynamiką, to tak, wybierz wersję okrojoną.

Moim osobistym stylem jest używanie takich zmiennych (których skróty są powszechnie znane w tej dziedzinie), ale umieszczanie ich opisu w komentarzach.

/* P : Pressure
   V : Volume
   n : Number of moles
   R : Boltzmann constant
   T : Temperature (in K)
*/
double compute_V(double P, double n, double T) {
  return n*R*T/P;
}

Po prostu wyrzucając go, masz inną opcję:

Volume ComputeVolume(Pressure p, Moles m, Temperature t) { ... }

Jest to nieco podobne do tego, co F # robi z jednostkami miary, i ma tę zaletę, że pozwala uniknąć problemów, takich jak przypadkowe zastąpienie ciśnienia przez temperaturę. Trudno wyobrazić sobie, jakie argumenty powinny iść tam, gdzie jest podpis (podwójne, podwójne, podwójne)

Wolę to:

/* This function calculates volume using the following formula:
 *
 *     n * R * T
 * v = ---------
 *         P
 */
double volume(double pressure, double n_moles, double temperature) {
    return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

Innymi słowy, wyjaśnij znaczenie kodu w komentarzu po angielsku (i matematyce; to komentarze, możesz rozwinąć go tak bardzo, jak to konieczne), ale używaj opisowych nazw zmiennych, aby każdy, kto czyta jedyny kod, był w stanie zrozumieć łatwo - zwłaszcza przy większych funkcjach. Innym powodem, dla którego używałbym prawdziwych słów jako nazw zmiennych, jest to, że interfejs jest znacznie bardziej przejrzysty, jeśli trzeba skopiować deklarację funkcji do pliku nagłówka.

IMHO zawsze lepiej jest używać ustalonej notacji domeny, w której pracujesz, jeśli funkcja jest bardzo specyficzna dla domeny. Ktoś, kto nie rozumie problematycznej domeny, nie ma szans na udane utrzymanie kodu, a dla kogoś, kto jest obeznany z domeną, długie nazwy będą po prostu szumem, a także więcej pisania.

OTHO, powiem, że chciałbym, aby konwencjonalna notacja matematyczna była czasem bardziej szczegółowa i opisowa, ale niezależnie od tego, czy uważam, że kod matematyczny powinien trzymać się konwencji matematycznej.

Edycja: Ta odpowiedź ma zastosowanie tylko wtedy, gdy istnieje bardzo silna konwencja notacji podczas pisania formuły matematycznie. Jeśli nie ma takiego, a trzeba by wyjaśnić, co zmienne reprezentują w komentarzu, nawet zakładając, że czytelnik jest zaznajomiony z domeną, najlepiej jest pomylić się po stronie bardziej opisowej konwencji.

Czysta opinia, ale zawsze używaj słów nad symbolami jednoliterowymi. Jeśli użyjesz słów, wszyscy zrozumieją; jeśli używasz symboli, tylko eksperci w tej dziedzinie mają gwarancję przestrzegania. Nawet wtedy niektóre osoby używają różnych symboli dla tych samych wielkości fizycznych. Używając dłuższych nazw, nie masz nic do stracenia.

Twoja troska powinna być jasność, a następnie poprawność (niepoprawny, ale czytelny kod można łatwo poprawić), dlatego twoja funkcja powinna być napisana w celu zachowania możliwości obsługi przez ogólny koder, o ile to możliwe. Komentarze nagłówka funkcji powinny wyjaśniać formułę i jej użycie oraz opisywać parametry wejścia / wyjścia. Odtąd sposób ułożenia ciała funkcji nie powinien mieć większego znaczenia, o ile jest zgodny z komentarzami nagłówka.

(Wiem, że to nie jest dyskusja, ale - moim osobistym wyborem byłoby nadanie zmiennym nazw wyraźnych, chociaż w tym przypadku wystarczy jedna linijka, ponieważ jest to funkcja „czysta”; wywołanie o tych samych parametrach dałoby to samo wynik zawsze, więc nie powinno być złożoności związanej ze stanem wymagającej wyjaśnienia)

• Jeśli chodzi o inne języki obsługujące analizę wymiarową, można to zaimplementować np. W C ++ z szablonami, biblioteka Boost Units korzysta z tego podejścia.

Zależy od tego, jak „daleko” od warstwy biznesowej jest kod ... Im dalej w stosie jest kod, tym bardziej jest on ukierunkowany na abstrakcyjne funkcje matematyczne, tym bardziej staram się naśladować ogólnie akceptowany notacje matematyczne i konwencje nazewnictwa. Im bliżej frontu lub warstwy biznesowej, tym bardziej bym się zgadzał z konwencjami ustanowionymi w dziedzinie problemów.

Lubię myśleć o tym w ten sposób - matematycy popełniali błąd, stosując krótkie zmienne, a fizycy postępowali podobnie . Po co powtarzać swój błąd? Wiemy teraz, że dłuższe nazwy są bardziej opisowe i powodują mniej zamieszania, więc trzymaj się ulepszeń. Mówiąc prościej, czasami próbuję podkraść dłuższe zmienne do moich obliczeń matematycznych, przy których wszyscy są przerażeni.

Prawidłowy format równania programującego to taki, który nadal rozumiesz po tym, jak nie widziałeś go przez sześć miesięcy.

Jeśli wrócisz do:

n*R*T/P;

I rozpoznajesz, co się dzieje, to chyba dobrze. Zazwyczaj w przypadku zaawansowanych formuł nie pamiętam, czym była każda część, chyba że aktywnie jej używam. Dla mnie:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

jest znacznie lepszym formatem równania, ponieważ mogę łatwo zrozumieć każdą część, nawet jeśli niekoniecznie wiem, dlaczego równanie jest napisane w obecnej formie.

Rzuć monetą.

Czy czasem spędzasz więcej czasu na zastanawianiu się, jak nazwać zmienną, niż na samym kodowaniu?