[GlenPL]

Cześć, poprawiłem kod według Twoich rad @MacDada.

https://github.com/Glenpl/Sapper

Tak jak radziłeś, nie przepisałem tego jeszcze obiektowo. Mógłbyś jeszcze raz spojrzeć na ten kod i powiedzieć co jeszcze wymaga poprawy?

W wielu miejscach mam jednak więcej niż 2 poziomy wcięć, bo nie wiem jak to dzielić tak, aby zachowało czytelność.

#naukaprogramowania #codereview #cpp

[MacDada]

@GlenPL: Dorzuciłem trochę komentarzy ;)

https://github.com/Glenpl/Sapper/commit/be5b3a07ca19276d07dae26277aaf2739d859018

[GlenPL]

@MacDada: dzięki, zaraz zacznę poprawiać to co wypunktowałeś i podzielę ten kod na 2 pliki jeden z kodem, a drugi nagłówkowy - nazbierało się już trochę deklaracji funkcji, typedefów itp. Pierwsza styczność z Gitem i żeby zaktualizować jeden plik zrobiłem chyba z 5 commitów ( ͡° ͜ʖ ͡°)

[MacDada]

@GlenPL: Trochę poużywasz to GITa docenisz – niesamowicie zwiększa produktywność :)

[MacDada]

@GlenPL: Dużo lepiej się to czyta :)

[GlenPL]

@MacDada: zaraz zrobię poprawki tych warunków o których napisałes. Muszę przyznać, że tak zorganizowany kod czyta się łatwiej :) gdyby jeszcze funkcje nie były porozrzucane w losowej kolejności... :D
Co masz na myśli mówiąc o zapisywaniu komunikatów do stałych? Mam zrobić funkcję, która po zapytaniu o konkretny komunikat (np. finishgamemessage) zwróci ten komunikat w odpowiednim języku bazując na wysłanej/zapisanej gdzieś zmiennej local albo language?

[MacDada]

@GlenPL: Jak do każdego komunikatu zrobisz funkcję, to się tych funkcji narobi od groma.

Nie wiem jak to sensownie w C++ uzyskać, ale najfajniej jakbyś miał plik ze wszystkimi tekstami i jedną funkcję, która na podstawie klucza i przekazanych parametrów przetłumaczy Ci komunikat.

gotowy_komunikat_do_wyswietlenia = translate(nazwa_komunikatu, parametr1, parametr2)

Liczba tych dodatkowych parametrów powinna być dowolna – tzn zależna

[GlenPL]

@MacDada: tak, mówię: "funkcję, która po zapytaniu o konkretny komunikat (np. finishgamemessage) zwróci ten komunikat w odpowiednim języku bazując na wysłanej/zapisanej gdzieś zmiennej local albo language", nie mam zamiaru robić do każdego komunikatu osobnej funkcji - to była by katorga, na dodatek dodanie nowego komunikatu to mnóstwo nowego kodu.

"Gratulacje, wygrałeś!" da się zrobić bez problemu, "Twoje imię to %s, potwierdzasz?" do sprawnego zakodowania funkcji obsługującej %s musiałbym chyba użyć kilku

[MacDada]

@GlenPL: Na codzień piszę w PHP i zrobiłbym to w ten sposób:

http://pastebin.com/qRCcsxsS

Tzn nie do końca bym tak zrobił, bo pisałbym klasę, nie używał globali, etc – ale proceduralnie tak to

[GlenPL]

@MacDada: ok, łapię Twoją koncepcję. Niestety w c++ nie ma kontenera słownika, max co można wyciągnąć na kontenerach z STL to map - kontener którego każdy element jest parą , jakby się zastanowić można trzymać kontener w kontenerze i wtedy mieć taką konstrukcję (kurcze, narysowanie tego może być trochę trudne i ciężkie do zrozumienia dla Ciebie jeśli nie znasz zasad działania kontenerów z STLa):

http://pastebin.com/5ZFztSQu

Przepraszam za to co właśnie

[MacDada]

@GlenPL: Jak nie wiesz jak sensownie robić słowniki, to nawet wielki switch nie będzie jakimś halo. W środku loc_message po prostu switchami/ifami zwróć odpowiedni komunikat.

To co ja u siebie miałem to tablica dwuwymiarowa (słownik w słowniku), żeby właśnie móc wygodnie wybierać dla klucza i języka na raz, ale w sumie to można to zapisać jako po prostu IFy z językami i IFy z formatami w środku lub odwrotnie.

Obczaj to, ułatwi

[MacDada]

@MacDada: Z kolei language trzymaj sobie jako jakąś globalną zmienną, bo inaczej przy każdym tłumaczeniu będziesz musiał ją przekazywać, a to niewygodne i tak czy siak skądś brać wartość będziesz ;)

[MacDada]

@GlenPL: No i jak dotąd nie miałeś w ogóle opcji tłumaczenia komunikatów – ale myślę, że to fajny challenge i jak już wyczaisz dobry sposób, to będziesz go używać też w innych programach (zwłaszcza jak jeszcze listę komunikatów byś trzymał w jakimś oddzielnym pliku :))

[GlenPL]

@MacDada: language nie musi być zmienną globalną, można przecież napisać to obiektowo i język trzymać jako pole obiektu. Teraz poprawię rzeczy które wypunktowałeś mi po ostatnim commicie, poczytam linki które podesłałeś i zastanowię się, jak rozwiązać ten słownik. Jeśli to by była, tak jak wcześniej pokazałem, mapa w mapie to można by było nawet napisy trzymać jako .txt i przy otwieraniu programu wywoływać funkcję która tworzy kontener przechowujący je w

[MacDada]

language nie musi być zmienną globalną, można przecież napisać to obiektowo i język trzymać jako pole obiektu.

@GlenPL: Zgadza się, jak proponuję zmiany to nie proponuję obiektowych tylko proceduralne – bo nie wiem na ile ogarniasz OOP ;)

Co do samej implementacji, szybki google znalazł mi np

[GlenPL]

@MacDada: jak już używać biblioteki qt to i od razu jakieś gui by wypadało zrobić :P za pierwszym razem spróbuję to rozwiązać na własną rękę

[MacDada]

@GlenPL: No to masz dwa tematy do rozkminienia: słowniki i variadic functions – obie rzeczy, które na bank w przyszłości będziesz chciał używać, więc spox.

[GlenPL]

@MacDada: właśnie zrobiłem commita z tymi małymi poprawkami, teraz zajmę się tym słownikiem :)

[GlenPL]

nie wiem jeszcze jak to jest z tymi variadic functions, ale mam nadzieję, że da się jakoś te argumenty roboczo ładować do kontenerów, bo STLowe kontenery w porównaniu do trzymania danych w stylu c to w wygodzie i przejrzystości jest niebo a ziemia :)