🚀 go-pugleaf

W dniu poniedziałek, 10 kwietnia 2017 19:21:57 UTC+2 użytkownik godek....@gmail.com napisał:
> W dniu poniedziałek, 10 kwietnia 2017 16:45:03 UTC+2 użytkownik (fir) napisał:
> 
> > > No cóż, jak nie widzę kodu, to też tak naprawdę ciężko mi się wypowiedzieć.
> > > Ja staram się pisać kod w taki sposób, żeby całkowicie siebie wyjaśniał,
> > > żeby nie było tam żadnych ukrytych założeń ani niewysłowionych konwencji.
> > > Funkcje, które zapisuję, odpowiadają pojęciom, którymi myślę.
> > > 
> > > Ale -- jak mówią -- whatever works. Dopóki nie muszę pracować
> > > z Twoim kodem, nie interesuje mnie Twój adres ;]
> > 
> > moj kod jest zupelnie dobry, mysle ze lepszy niz twoj ;c
> 
> Nie będę się spierał, bo jak mówiłem, nie widziałem
> zbyt dużo Twojego kodu (tylko biblioteczkę, którą
> gdzieś tam ostatnio wklejałeś, choć przyznam, że lepiej
> do takich rzeczy używać gista albo pastebina, niż
> usenetu)
> 
> > aczkolwiek nie kazdy by tak pewnie uwazal bo ludzie oceniaja pod siebie, 
> > a ja mam wlasny styl nazewnictwa pascalem i raczej dlugimi nazwami ktory
> > to styl moze nie wyglada za dobrze (styl z kreskami na na krotkich nazwach
> > na oko wyglada przyjemniej) ale dla mnie jest logicznie
> > ok.. ogolnie swoj kod uwazam za dobry (choc pare lat to zajelo
> > by wypracowac styl)
> 
> A umiałbyś określić kryteria, w oparciu o które stwierdzasz,
> że Twój kod jest dobry?
> [Bo w sumie "dobry" to szalenie relatywne pojęcie. Dla mnie
> dobry kod to taki, który jest zasadniczo sformułowaniem
> problemu, który rozwiązuje. Dobry kod w moim odczuciu powinien
> być dedukowalny, tzn. ilekroć zetknę się z takim samym
> problemem, powinienem wyprodukować mniej więcej identyczny
> kod]
> 

moj kod jest dobry poniewaz nie jest zly, nie ma zasadniczych powodow do ktorych mozna by sie 
przyczepic (chyba ze czepia sie jakis typowy baran
ktory nie wie co mowi) - jest dobrze napisany,
binarne mechanizmy ok, warstwa wygladowa tez ok
 

> > pewne rzeczy bede jednak probowal ciagle usprawnic np wspomniany
> > 'krzak' (tak nawywam obszary kodu ktorych kod i flow jest
> > rozproszony po przestrzeni projektu zamiast byc ladnie
> > pofaktoryzowany na moduly z pojedynczymi punktami wejscia)
> > trzebbedzie nad tym popracowac
> 
> Trochę to co piszesz, kojarzy się z programowaniem aspektowym
> [którego raczej nie rozumiem, choć gdzieś się spotkałem
> ze stwierdzeniem, że haskellowe monady stanowią jakąś tam
> realizację programowania aspektowego]

mi sie kojarzy z odejsciem od programowania proceduralnego w programowaniu proceduralnym (w strone zagmatwanego programowania blokowego)

to co akurat mowie jest chyba wymuszone przez windowsową kolejke eventow (ogolnie model eventowy)

zarysuje przyklad,->  masz gre ktora ma zalczony pod-stan 
dodatkowy ekran (np z ekwipunkiem) ktory obslugujesz z klawiatury (wciskasz klawisze i cos tam sie dzieje na ekranie z ekwipunkiem) - ten pod-stan gry przejmuje klawisze z handlera eventow "key down" (tj jest podpiety
pod ten globalny handler)  teraz wyobraz sobie ze
z tego ekranu chesz sie przelaczyc na jakis inny ekran
(ktory tez przechwytuje klawisze, czyli tez podpinasz 
ten drugi pod glowny handler eventow (i wybierasz ktory jest aktualnie wlaczony po jakims incie czy enumie (ktoray ja nazywam selektorem)).. i tu pojawiaja sie problemy.. nie wiem co tu jest nie tak (zeby wiedziec musialbym sie glebiej zastanowic) ale mozje pobieżne obserwacje wykazuja ze cos tu jest nie tak..