Zdravíčko, dnes som si uvedomil že vo všetkých algoritmoch ktoré navrhnem používam veľmi často "if" podmienku. Mal by som sa nad sebou zamyslieť a hladať vždy matematickejšie/efektívnejšie/viac frajerské riešenia alebo je to nepodstatné a hlavne že to funguje? Ďakujem za odpovede

//autoeditácia príspevku (30 Jún 2015, 16:13)
btw aby bola moja otázka plne pochopená tak mi má čoskoro prísť Arduino a chcem tie príkazové programy písať čo najeefektívnejšie, preto to vôbec riešim

no a konkretne? ukaz nejaky kus kodu, ktory sa ti zda byt prepodmienkovany.

ťažko nájsť konkrétny kus, ale napr.
kde som vyberal "náhodný" smer v Pong hre pre loptu. Mne skôr ide o všeobecné zhodnotenie či je časté používanie podmienok v poriadku alebo je to neefektívne spracovanie algoritmu, je mi jasné že niekedy sa tým podmienkam človek nevyhne.

Niekedy sa im nevyhnes. Pokial ich nemas stovky hned za sebou, tak to je ok. Ja som mal raz jednu cast kodu kde som mal asi 15 if/elseif za sebou a v nich dalsie ify
Samozrejme to bolo len aby to fungovalo, potom som sa k tomu vratil a upravil to, namiesto cca 25 ifov som to skratil na asi 6. Takze vsetko sa da, len treba porozmyslat, niekedy ti to hned nedocvakne, tak si proste tu cast kodu oznac a vrat sa k nej neskor.


K pongu, davnejsie som robil pong v pythone, mozes sa pozriet na to ako je robeny: http://www.codeskulptor.org/#user40_d3PdbSc6WR54zvF.py (vlavo hore je ► tlacidlo).

no napriklad toto sa da napisat prehladnejsie, vygenerujes random.randint(0,3) a potom switch pre hodnoty 0,1,2,3 ... a ked mas len 1 volanie metody namiesto dvoch tak to bude asi aj o nieco rychlejsie

@Michaelo presne ten istý kurz na coursere práve absolvujem takže si tvoje spracovanie rád pozriem ale až keď odovzdám vlastné
@ropman čo presne myslíš pred switchom? napísal by si mi ako to má vyzerať?

podla mna je to v pohode, pokial nemas podmienku ifu na 4 riadky ako kolegovia na svojom projekte a este k tomu ani stipka komentara, pretoze "komentare pisu iba ludia, ktori nepisu self-explainatory kod"...

ďakujem, tak to budem teda vždy hladať najefektívnejšie riešenie a pokiaľ bude obsahovať podmienky tak si z toho ťažkú hlavu robiť nebudem

alebo kod OOP, tym podobne podmienky eliminujes

Mr-Freek napísal:@Michaelo presne ten istý kurz na coursere práve absolvujem takže si tvoje spracovanie rád pozriem ale až keď odovzdám vlastné

Ale, znovu ho otvorili? Skoda ze som o tom nevedel, by som si ho rad spravil znovu. Ten Pong som zbuchal asi za 2 ci 3 dni... Chcel som sa k nemu vratit a o cosi ho vylepsit, ale nejako som sa nan potom vykaslal

Drzim palce teda. Ja som tam asi strail len jeden bod pocas celeho kurzu ak sa nemylim.

mirak2: nepovedal by som, že je to v pohode. V kvante podmienok sa nedá vyznať, treba to rozbiť do funkcií alebo prepísať kod na logickejší. Toto by som riešil presne ako napísal ropman, alebo si tie smery definovať v poly ako prípustné smery a potom zavolať spawn_ball s náhodným prvkom pola, keďže do tej funkcie vstupuje iba reťazec. A prečo tie podmienky nie sú v pohode, je napríklad prípad že chce pridať nové smery:
1) v jeho riešení to bude ďalšia vnorená podmienka v každej podmienke. To bude ak dobre počítam 5 ifov a celé to bude maximálne neprehladné. Už len napísať to tam tak aby sa nepomýlil zaberie energiu a čas, nie to ešte čítať ten kod keď sa k nemu niekto po čase vráti a bude potrebovať niečo upraviť
2) ropmanove riešenie by potrebovalo pridať jednu case vetvu. Takmer žiadna režia, ale musí si nájsť kde sa tieto pohyby riešia
3) riešenie s poľom by predstavovalo pridanie jedneho prvku niekde hore v deklaracii pola, a nemusím vôbec hladať kde v kode sa rieši pohyb a kde všade sa to používa.

@audiotrack: suhlas. akurat v Pythone nemas switch, t.j. v tomto pripade by asi bolo lepsie pouzit funkcie a ulozit si ich do slovniku.

Mr-Freek napísal:ťažko nájsť konkrétny kus, ale napr.

Kód: Vybrať všetko

    if random.randint(0,1) == 1:
        if random.randint(0,1) == 1:
            spawn_ball("Uleft")
        else:
            spawn_ball("Dleft")
    else:
        if random.randint(0,1) == 1:
            spawn_ball("Uright")
        else:
            spawn_ball("Dright")

kde som vyberal "náhodný" smer v Pong hre pre loptu. Mne skôr ide o všeobecné zhodnotenie či je časté používanie podmienok v poriadku alebo je to neefektívne spracovanie algoritmu, je mi jasné že niekedy sa tým podmienkam človek nevyhne.

spamati pisany kod v jave (nerucim za spravnu syntax) - nie je to python a bolo to tu uz spomenute ale na pochopenie by ti to malo stacit //edit: xadman - vidis, este jednoduchsie ako v jave

V pythone to bude vyzerať nejak takto

už som to vyriešil iným spôsobom ale toto vyzerá dobre, určite si to zapamätám a keď bude treba použijem ďakujem

Toto je na konkretny problem ale ak by si to chcel vseobecne tak:

1. Bud lenivy. Kopirovat kod a robit v kopiach minimalne/ziadne zmeny je zle. Kod mas znovu pouzit, nie kopirovat.
2. Bud lenivy aj do buducna. Poloz si otazku co sa stane ak to chces rozsirit. Skus kodit tak akoby si mal mat kofigurak a menit medzi povodnou a novou funkcionalitou (pripadne inou) len v nom.
3. Bud lenivy a dopraj aj pripadne inym lenivost. Kod ma byt rozumitelny a zlozitejsie veci okomentovane. Toto ma dva aspekty - jednak ulahcis pochopenie ked ty sam alebo niekto iny bude po case kod studovat a nuti ta to opisat problem a riesenie. A vsetci mame skusenost, ze riesenie problemu nam napadne prave vtedy ked to vysvetlujeme niekomu inemu.

s tým tretím bodom celkom nesúhlasím. Tiež nás učili v škole komentovať, a nezabúdať na komentáre, ale až keď som začal programovať veci ktoré sa udržujú dlhé roky, a na ktorých pracuje kopec ľudí súčasne, naučil som sa dve zásadné veci, prečo nekomentovať (nie je to môj objav, dočítaš sa to aj v literatúre, napr. Čistý kod, len som si uvedomil pravdivosť toho):

1) kod má byť samopopisný. AK niečo potrebuje komentár, je to zle napísané. Ak budú mať premenné názvy ktoré vysvetlujú čo v nich je (nie $array ale $arrayOfPersons), metody ktorých názvy dávajú zmysel (nie redirect ktorá okrem redirectu robí aj kadejaké podmienky, ale napr. redirectIfNotLogged), podmienky stavané na zhodu a nie negáciu a plno iných best-practices, tak kod vôbec nepotrebuje komentár, lebo v ňom čítaš ako v knihe a všetkému rozumieš. Vieš čo tá metoda robí bez toho aby si do nej musel pozreť. Vieš čo v tej premennej je (alebo bude), dokonca či je dočasná alebo nie a plno iných vecí už len z jej názvu.

2) komentáre zastarávajú skôr ako kod. 95% programátorov keď zmení kod, neupraví aj komentár. Komentáre sa potom stávajú dezinformujúcimi a mätúcimi a namiesto toho aby pomohli ťa iba zdržia lebo klamú. Taktiež vyjadrovacie schopnosti programátorov sú často na nízkej úrovni (nie sú predsa spisovatelia či herci), a komentáre sú často nejasné nakoľko nie sú jednoznačné ako kod. Tu mám na mysli prípad chýbajúcej čiarky: http://webmagazin.teraz.sk/zivot/ciarka ... lanok.html Neraz som sa stretol s chybou v komentári, kde bola opačná rovnosť (namiesto > bolo <) a podobne. V kode by sa to objavilo testovaním, v komentári nikto nezaručí správnosť že programátor nespravil preklep. Nehovoriac o celej množine doslova zbytočných komentárov písaných v jazyku programátora a uverejnených ako open source. Keď otvorím zdroják a vidím tam 30 riadkov v španielčine, no načo je mi taký komentár?

nevravím že v kode nemá byť ani jeden komentár. Vravím iba, že tam majú byť len nevyhnutné. Takými je napríklad phpdoc (javadoc, prípadne iná dokumentačná syntax, ktorá pomáha aj IDE-čkam) alebo vysvetlenia na vonok nejasných myšlienok (prečo sa niekde nepoužil taký spôsob sortovania ale nejaký iný ktorý je všeobecne známi ako menej efektívny a pod.)

..nuti ta to opisat problem a riesenie. A vsetci mame skusenost, ze riesenie problemu nam napadne prave vtedy ked to vysvetlujeme niekomu inemu.

v čase písania kodu už má mať presnú predstavu ako problém vyriešiť. Ak nemá poňatia ako ho vyriešiť a musí si písať komentáre aby ho to napadlo, tak zanedbal analýzu problému a nech sa vráti späť k UML diagramom kde si to všetko jasne popíše. A aj ostatným

Na tuto temu je dobra kniha http://www.martinus.sk/?uItem=73286, vrelo odporucam.

Preto pisem, ze zlozitejsie veci maju byt okomentovane. Jednoduche veci a veci jasne z dokumentacie komentovane byt samozrejme nemaju.

S dvoma vecami ale nesuhlasim uplne:
1. Ak nieco potrebuje komentar tak je to zle napisane. Napis mi napr. Dijsktrov algoritmus tak aby som pochopil len z nazvov premennych ako funguje (a Dijkstra nie je zlozity aby sa to nedalo).
2. Programator ma mat jasno v tom ako bude dany problem riesit. Skusenosti ma naucili, ze nieco ako dokonala analyza neexistuje a popri programovani narazam na kopu "pod-problemov" za behu. Samozrejme by sa dali eliminovat tou dokonalou analyzou - lenze ta nie je mozna a preto asi 70%SW firiem pouziva agilne metodologie a neprehana to s analyzou.

Nechap to zle, ze "musi si pisat komentar aby ho to napadlo" (od toho sa pisu/kreslia UML diagramy). Skor ak sa snazi vysvetlit co prave urobil a sameho ho napadnu mozne nedostatky.

Samozrejme sa mozem mylit, knihu si zozeniem a rad sa necham poucit. Takze ak ma dokazete jednoducho vyviest z omylu tak sa rad necham poucit ak to jednoducho nepojde tak rad budem studovat.

Argument voci ktoremu nemozem namietat nic je ze pri uprave kodu sa uz nikomu nechce upravit komentare.

audiotrack napísal:.... AK niečo potrebuje komentár, je to zle napísané...

Tak s tymto vobec nesuhlasim. Trochu komplikovanejsi alogoritmus alebo vacsi framework a a clovek je strateny.