🚀 go-pugleaf

W dniu piątek, 7 kwietnia 2017 16:24:13 UTC+2 użytkownik (fir) napisał:
> W dniu piątek, 7 kwietnia 2017 16:02:27 UTC+2 użytkownik (fir) napisał:
> > W dniu piątek, 7 kwietnia 2017 15:31:12 UTC+2 użytkownik (fir) napisał:
> > > W dniu piątek, 7 kwietnia 2017 12:15:43 UTC+2 użytkownik godek....@gmail.com napisał:
> > > > W dniu piątek, 7 kwietnia 2017 11:52:09 UTC+2 użytkownik slawek napisał:
> > > > 
> > > > > > Napisałeś, że uważasz, że na 40 linii kodu powinno=
> > > > > >  przypadać
> > > > > > 50 linii komentarza, ale nie napisałeś, dlaczego
> > > > > 
> > > > > Bo jeżeli piszę wysokopoziomowo, np. wywołując jakieś 100 różnych 
> > > > > funkcji/metod w 40 linijkach, to robi się coś konkretnego. Te coś 
> > > > > konkretnego wymaga opisania: co się robi, jakie parametry, jakie 
> > > > > skutki, co powinno być a co nie,
> > > > 
> > > > Według mnie:
> > > > 
> > > > To, co się robi, powinno wynikać z nazwy funkcji.
> > > > To, jakie parametry, powinno wynikać z nazw tych parametrów,
> > > > albo czegoś w tym rodzaju -- ja jak piszę w Schemie, to daję
> > > > jednosłowowe komentarze "przyimkowe", wyjaśniające role
> > > > poszczególnych argumentów, np. w kodzie rozwiązującym
> > > > problem komiwojażera miałem coś w stylu
> > > > 
> > > > (shortest-path+cost #;from start #;to end #;through others)
> > > > 
> > > > To, jakie skutki, powinno wynikać z asercji/kontraktów.
> > > 
> > > 
> > > no asercje bylyby lepsze niz komentarze, ale nawet ich tez nie chce mi sie pisac - moze musze nad sobą popracowac w tym etemacie
> > >  
> > > (tj przetrenowac jak to jest kompatybilne z moim 
> > > stylem klepanie i patrzenia na zrodlo)
> > > 
> > 
> > 
> > by wspomniec oczywista rownowage kosztow do zyskow
> > 
> > koszty:
> > 1) trzeba je wpisywac, jesli bym tego wpisywal setki -
> > a raczej bylyby setki - to jakis koszt jest
> > 
> > 2) wydluzaja zrodlo a dluzsze zrodlo jest troche 
> > gorsze i byc moze wolniejsze w czytaniu
> > 
> > zyski:
> > 1) jesli juz cos wylapią to b dobrze, od czasu do czasu
> > zaoszczedzą troche z nieprzyjemnej sesji lokalizowania
> > bledu
> > 2) nie uzywam assertow ale od czasu do czasu uzywam 
> > if(..) ERROR(..), gdyby to byl assert to mozliwosc wylaczenie tego przez NDEBUG jest dobra do optymalizacji
> > 
> > mixed:
> > 
> > 1) - z drugiej strony jest maly problem bo niektore a tych assercji byc moze chcialbym zostawic w release, a 
> > rozkminianie teraz za kazdym razem co robic ifem a co assertem moze byc deczko spowoalniajace
> > 
> > 2) assert w windzie wywala okno i fatalny dzwiek ("d-dum-b!"), ktorego nie lubie i nie chcialbym tego sluchac,
> > moje wlasne okno od erroru daje nieco lepszy "t-trrik!")
> > do tego u mnie w dialogu przycisk "ignore error" (czasem przydatny)  dziala  a ten od assertu nie wydaje sie dzialac leci po nim u mnie sigsegv nie wiedomo czemu
> > 
> > 3) pozatym chyba wolalbym to pisac duzymi literami ASSERT
> > czyli musialbym napisac swoj 
> > 
> > tak ze nie wiem, w sumie na razie by nie komplikowac chyba nie bede uzywac
> > 
> 
> problemem przekonujacym mnie do tego jest chyba wlasnie to ze jesli napisze swoj wlasny ASSERT_() 
> (kiedys pisalem i to bylo cos w stylu
> 
> #ifdef NO_ASSERTS
> #define ASSERT_(p)          ;;;
> #else
> #define ASSERT_(p)     if(!(p)) (show_assert_failed_dialog( #p, __FILE__, __LINE__))
> #endif
> 
>  void show_assert_failed_dialog(char* condition,
>                                 char* file,
>                                  int line)
>  {
>    ERROR_("\nAssertion  (%s) failed \n\n %s %d  " , condition, file, line);
>  }
> 

z drugiej strony samo dodatkowe makro moze i by uszlo  kiedys z jakichs dziwnych powodowd wydzialalem na dwie funkcje)

#define ASSERT_(p) if(!(p)) ERROR_("\nAssertion (%s) failed \n\n %s %d  ", #p, __FILE__, __LINE__);


> cos w tym stylu to jako ze jest to makro musze to przeklejac headerem a ERROR_ ciagne jedna linijką importu z dll-ki, lamaloby to tez moja zasade nie uzywania makr
> 
> assert z headera c z kolei nie ma tych wad ale jest malymi literami (co jest niespojne u mnie bo wole duzymi)
> i wola okno z glupim dzwiekiem (a tu wyzej moga dac nawet wyczesany dialog z pelna diagnostyka gdyby mi sie chcialo
> 
> > 
> > > > Zresztą wydaje mi się, że w tym przypadku wartość programowania
> > > > funkcyjnego jest szczególnie duża, bo zazwyczaj funkcje nie
> > > > mają skutków, tylko wartości, a jeśli mają skutki, to w Haskellu
> > > > albo Scali wynika to z typu.
> > > > 
> > > > > jaki algorytm i gdzie coś można poczytać (referencje). 
> > > > 
> > > > Tego, jaki algorytm, albo referencji, rzeczywiście nie da się
> > > > zawrzeć poza komentarzem, ale to zazwyczaj jedna linijka.
> > > > 
> > > > > To będzie już 30 do 40 linijek komentarza. Do 
> > > > > tego jeszcze kilkanaście w tekście, np. że nie robić czegoś 
> > > > > oczywistego, bo dany fragment musi być taki właśnie jaki jest.
> > > > >
> > > > > I już jest nawet i 50 linii komentarza. Zwłaszcza że liczę takie 
> > > > > 
> > > > > A=5; // cm
> > > > > 
> > > > > za linię z komentarzem.
> > > > 
> > > > Chyba lepiej byłoby tak:
> > > > 
> > > > A_cm = 5;
> > > > 
> > > > Pod tym względem ciekawe rozwiązanie ma F#:
> > > > https://en.wikibooks.org/wiki/F_Sharp_Programming/Units_of_Measure