Czytelność kodu: trzymanie danych w obiektach z dokumentacją czy klasach ?

Mam w kodzie tablice przechowującą obiekty miast, które oprócz kilku własnych wartości, przechowuje tablicę tablic pytań dotyczących miasta, a każde z tych pytań zawiera szereg własnych wartości itd.. Burdel, że tak powiem.

Problem jest taki, że takie wartości w kodzie są czytelne tylko dla programisty które je tam umieścił, a i to tylko przez krótki czas.

W jaki sposób radzicie sobie, bez statycznego typowania, z zarządzaniem większymi zbiorami danych? Ja mam trzy pomysły:

1. Klasy ES6 zamiast trzymania tego w dzikich obiektach. Definicja klasy dobrze pokazuje co w niej jest. Nie wpłynie to na wydajność?
2. Funkcja zwracająca obiekty. Jej treść powinna podpowiadać, co znajduje się wewnątrz obiektu.
3. Dokumentacja w stylu doxygen nad takimi parametrami, opisująca z czego dokładnie się składa.

Ja jako ze wychowany na backendzie to dla mnie idealnym roziwazniem jest typowanie dlatego w js pisze tylko uzywajac typescriptu. Ale odpowiadajac na twoje pytania:

1. Jasne ze nie, tak samo kilka mniejszych funkcji wcale wolniej nie dziala niz jedna duza, kod powinien byc czytelny :D
2. Well tu az sie prosi o typescript ale siedze cicho :D. Tak nazwy funkcji powinny mowic co dana funckja robi znow podstawa clean code ;).
3. W pewnych miejsach tak, ale watpie bys wszystkie funckje tak dokumentowal.

Anyway polecam sprobwac zapoznac sie z typescriptem ;)
np. https://stackify.com/typescript-vs-javascript-migrate/

Typescript byłby idealny, albo jakikolwiek język silnie typowany. Niestety, kod o którym mówię jest częścią projektu QtQuick, czyli w grę wchodzi tylko czysty ES6. Ponad 10k linii czystego, nieskalanego dokumentacją i testami JavaScriptu.

Widziałem kilka benchmarków, wskazujących że klasy działają ogólnie wolniej. Alternatywy jednak chyba nie ma, to najczytelniejszy sposób.

ty tak na serio z tymi benchmarkami? przecież to są realnie żadne różnice, zwłaszcza, że kod jest wykonywany po stronie użytkownika. zrozumiałbym, gdyby kod śmigał na serwerze, który obsługuje 10k requestów na sekundę, ale w tym wypadku argument wydajności jest inwalidą. napisz to tak, żeby było czytelnie i nie przejmuj się jakąś mikrooptymalizacją. nie wiem jak działa QtQuick, ale czy coś stoi na przeszkodzie, żebyś kompilował kod w TSie do ES6 używał go w QtQuick?

Pzt ten benchmark nie jest miarodajny, kod bez klas przy dziedziczeniu, ani nie wywołuje konstruktora klasy bazowej, ani nie przypisuje (.prototype.constructor). Pzt większość wbudowanych konstruktorów nie może być bezpiecznie w ten sposób dziedziczona(bez użycia klas).

Także kompletnie bym się takim benchmarkiem nie sugerował bo to nie jest alternatywa.

QtQuick to rozszerzenie Qt, frameworka GUI, jak JavaFX, GTK itd.. Mam ES6, ale niekompatybilne ze standardowymi narzędziami do tego 'webowego' JS. Taka uboga wersja.

@iksde
Większość już przepisałem na klasy. Problem jest z jednym miejscem, które już teraz stanowi wąskie gardło. Z dwojga złego, lepiej żeby ten kod był nieczytelny, niż niewydajny. Jeszcze dzisiaj sprawdzę czy różnica jest do zaakceptowania.