|
boni01: [^janekr] IMHO taka konstrukcja jest nieco kiepska (jw. "z dupy wyjęta"). Raczej nie zrobiłbym w ten sposób zagnieżdżeń dialogów, czy ogólniej asynchronicznej komunikacji z (kim/czym)kolwiek, no ale to ja a.k.a paranoid. |
|
2016/11/28 19:19:48 przez www, 0 ♥
|
|
|
boni01: [^gliniany] Wynikanie zachodzi akurat w drugą stronę, dowcipnisiu ;) A od pascala proszę się odstosunkować, nadal najprzyjemniej i najszybciej drobiazgi mi się pisze i DEBUGUJE w jakimś starym Delphi. |
|
2016/11/28 19:04:06 przez www, 0 ♥
|
|
|
boni01: [^boni01] i jakoś nie lubię return dla normalnego wykonania, jest takie be. Plus parę pomniejszych zalet else w środku, ale to już zależy od metody czy tam metodologii, czy to agile czy zdarzeniowe czy inna cholera. |
|
2016/11/28 18:59:40 przez www, 1 ♥
|
|
|
boni01: [^janekr] Czyli praktycznie to samo co zmalowałem plus to co dopisałem o ew. użyciu zmiennych pomocniczych. A co do else w środku - ja wolę z else bo ładnie wyróżnia graficznie wykonanie od obsługi błędów > |
|
2016/11/28 18:58:01 przez www, 0 ♥
|
|
|
boni01: [<usunięty>] Obsługa przejść true-false i false-true (zboczy opadających i wznoszących, jak ktoś woli oscyloskopem polecieć), plus wcisnęli forcing, tak bonusowo. |
|
2016/11/28 18:51:00 przez www, 0 ♥
|
|
|
boni01: [^janekr] Znaczy, serio sugerujesz, że w podanych przykładach należy założyć, że dowolna funkcja stageX jest niewalidowana co najmniej tak, jak dyskutowana funkcja foo i że ew. rozwiązanie zmiennymi resX nie wystarczy? Okeeej... |
|
2016/11/28 17:49:58 przez www, 0 ♥
|
|
|
boni01: [^janekr] IMHO jeśli ten system miałby być taki, jak sugerujesz, to znaczy, że jest z głębokiej dupy wyjęty i może lepiej napisać go od nowa. |
|
2016/11/28 17:43:09 przez www, 0 ♥
|
|
|
boni01: [^janekr] Jeśli kompilator/interpreter jest choć śladowo optymalizowany, no to niekoniecznie dwa razy. A ogólniej, jeśli stageX nie można wykonywać wielokrotnie, są niszczące, są real-time, no to zagadnienie jest zupełnie inne. |
|
2016/11/28 17:41:22 przez www, 0 ♥
|
|
|
boni01: [^boni01] ale czy pojmuje ją choć 50% inż. używających na co dzień tego stuffu i okolic? Myślę, że bardzo wątpię. |
|
2016/11/28 17:38:14 przez www, 0 ♥
|
|
|
boni01: [<usunięty>] Pewnie. Pozornie zmieniając temat ;) nie chcesz wiedzieć, jak to bywa "na zapleczu". Np. można zrozumieć różnice między typami BOOL i EBOOL w rozwiązaniach Wiodącego Dostawcy Automatyki > |
|
2016/11/28 17:37:25 przez www, 0 ♥
|
|
|
boni01: [^boni01] i oczywiście ni [censored] w [censored] pojąć nie mogę jak ktokolwiek może być idiotą konstruującym "typowanie" jak w PHP czy VB(A), powinno się tych ludzi pod mur, dla przykładu i for Greater Good. #programowanie |
|
2016/11/28 17:08:48 przez www, 1 ♥
|
|
|
boni01: [^gliniany] Żebyś wiedział! ;) generalnie, ponieważ ja dłubię w środowiskach, które można sklasyfikować w okolicach pomiędzy assemblerem a Forth ;) przeważnie pożądam "strong typingu" na poziomie durnego C chociaż. > |
|
2016/11/28 17:06:35 przez www, 0 ♥
|
|
|
boni01: [^boni01] I zdaje się co bardziej spektakularne błędy z tego się biorą, bo przecież "nasze narzędzia są spoko", tylko potem okazuje się, że narzędzie A koduje true jako 255(byte), B jako 1(int), a C jako "1"(string)... #programowanie |
|
2016/11/28 16:59:09 przez www, 0 ♥
|
|
|
boni01: [<usunięty>] Np. brak skutecznej walidacji typów. Jeśli twój system dopuszcza jakieś rzutowania czy inne głupoty w temacie, albo jak u mnie przeważnie: wcale nie ma walidacji, to dupa zbita,nie wyobrażam sobie, że można mu ufać. |
|
2016/11/28 16:56:20 przez www, 0 ♥
|
|
|
boni01: [<usunięty>] Dlatego napisałem "w szczególe", bo to nie jest point w temacie logiki i jakości kompilatora/interpretera, tylko w temacie "ile lat będzie się ew. błąd telepał po systemie i ew. ile dni będziesz go szukał" ;) #programowanie |
|
2016/11/28 16:52:57 przez www, 0 ♥
|
|
|
boni01: [^boni01] W szczególe, w moim świecie brak uchwytu dla "error spoza listy", najlepiej z wyjściem runtime-pseudo-debuggerem, to jest b.poważna wada, nie przeszłoby u mnie review, gdyby jakieś były ;D |
|
2016/11/28 16:35:23 przez www, 0 ♥
|
|
|
boni01: [<usunięty>] [<usunięty>] #programowanie Cieszę się, że się rozumiemy ;) Fakt, narzędzia badziewne, ale - nie ma narzędzi dostatecznie foolproof. > |
|
2016/11/28 16:33:46 przez www, 0 ♥
|
|
|
boni01: [^boni01] W sumie, to mógłbym mały wykład popełnić, dlaczego moja wersja jest naprawdę agile, w przeciwieństwie do wszelkich badziewnych wersji, jakie ^arc zaprezentował ;D |
|
2016/11/28 16:18:46 przez www, 0 ♥
|
|
|
boni01: [^gliniany] Jeśli jest na serio coś wykonującą, to robisz jak ^arc we wcześniejszych przykładach, zmienne res cośtam na początku. Ważniejsze, jak jest kompilowana logika na zylionie && i negacji w danym środowisku. |
|
2016/11/28 16:14:49 przez www, 1 ♥
|
|
|
boni01: [<usunięty>] Ja tam wolę jeszcze inaczej, znaczy, w wersji wzorcowej, bo oczywiście nie zawsze da się albo chce się albo warto; to byłoby pewnie coś w duchu #programowanie |
|
Pobierz obrazek (55.9kiB)
|
|
2016/11/28 16:08:42 przez www, 0 ♥
|
|
|
boni01: [^boni01] i czy na pewno ktokolwiek przeanalizował czy i w którą stronę ten kod jest fault tolerant, zamiast rozważać zagnieżdżenia i przewijanie ekranów... |
|
2016/11/28 15:09:53 przez www, 0 ♥
|
|
|
boni01: [<usunięty>] Powtórzę się - marudzisz ;P BTW np. u mnie nie ma żadnych sensownych standardów czy review, nikogo nie obchodzi ile tam jest klamerek czy linii, ale dostalibyście/łbyście za logikę tych kawałków itd. > |
|
2016/11/28 15:08:52 przez www, 0 ♥
|
|
|
boni01: [^boni01] Bo mam wrażenie, że czepiasz się pierdołek jak kolor papieru na jakim to wydrukowano; może ja w tym widzę pewne opcjonalne babole, ale dalekie od tego jak to jest powcinane czy ile linii zajmie, czy else czy srelse, itp. |
|
2016/11/28 14:59:46 przez www, 1 ♥
|
|
|
boni01: [<usunięty>] [<usunięty>] Poczekaj, to jaka jest wg ciebie właściwa wersja, skoro obie konstrukcje, "if (error) x else y" oraz "if (!error) y else x", hejtujesz? |
|
2016/11/28 14:58:06 przez www, 0 ♥
|
|
|
