Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Android development ma s javou pramalo spolecneho. Tedka se tam dere do popredi Kotlin a java pomalu vymizi. Vetsi penize budou urcite u te backendove javy.
Kotlin je ezotericky jazyk. Ak by java z androidu vymizla, tak si google pod sebou odpili konar.
Radsej C# ako Javu. Dokonca Oracle zavadza licencovanie javy, som zvedavy ako sa s tym vysporiadaju firmy ako google a ine, ktore vyvijaju v jave. Licencovat to ano, ale pridat nove features to nie.
Jdi do backendu a místo Javy se zaměř na modernější C#.
neco DOzadekE neni bud a nebo, ale ze je tam ku*va SKALAScala? Ta je funkcionální.
Všichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...Já se k tomu náhodou přidávám. Pipe operátor ("|>"), který mívají funkcionální jazyky (např. F#, Elixir. Haskell má podobné "$") je neuvěřitelně návykový. Hlavně proto, že se kód čte zleva doprava a ne obráceně. Funkce více argumentů nejsou větší problém. Osobně jsem si na to hodně zvykl a přijde mi to daleko čitenější než haskellovské skládání využívající curryfikace (YMMV).Kód: [Vybrat]list = ["a", "b", "c", "d"]
list |> Enum.reverse() |> Enum.join("/")
# vysledek: "d/c/b/a"
versusKód: [Vybrat]list = ["a", "b", "c", "d"]
Enum.join(Enum.reverse(list), "/")
# vysledek: "d/c/b/a"
(obojí Elixir)
Napr. v shelluVšichni kolem jsou debilové, ale s funkcemi víc argumentů tě počítat nenapadlo...Kód: [Vybrat]cat x | praveJsemNecoSpocital | druhaFunkce > velkyHovno.txt
Tak zrovna u shellu těch závorek obvykle není moc potřeba, ani když je těch parametrů víc. Akorát všichni víme, jak je v něm snadné střelit se do nohy.
Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.
Takže velký projekt poznám podle toho, že používá uměle nafouklé třídy?
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Vsichni sardel. Kule.
Tyhle zavorky jsou peklo at uz to jsou S expressions v lispu nebo M expressions nebo obdobnej zapis v algol derivatech (tj. 90% toho co znate).
Kolikrat se vam stalo ze napisete nejakou funkci praveJsemNecoSpocital(x) a chcete to poslat do druhy funkce. Jako debil musim psat druhaFunkce(praveJsemNecoSpocital(x)). Musim hloupe psat kus funkce pred tim puboenim kodem a zavirat zavorku za kodem. Pitomost. Obzvlast kdyz pracuju v REPL modu.
Alespon to muzu v tech algolech ulozit do promenny.
velkyHovno = druhaFunkce(praveJsemNecoSpocital(x))
Peklo je to v SQL, kde aspon v tech novych existuje ochcavka na promenny jmenem CTE, jinak je to absolutne nepouzitelnej pekac.
Idealni zapis je konkatenativni, tj. skladani programu za nebo pred sebe. Tim se vyhnu vsem temhke blbym promennym a psani zavorek jak debo.
Napr. v shellu
cat x | praveJsemNecoSpocital | druhaFunkce > velkyHovno.txt
Nebo jq
x | praveJsemNecoSpocital | druhaFunkce | . as $velkyHovno
Nebo forth
x praveJsemNecoSpocital druhaFunkce velkyHovno !
Nebo APL a derivaty, kde se pise prefixe. misto postfixem
velkyHovno: druhaFunkce praveJsemNecoSpocital x
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
takže podľa tebe je jednoduchšie povedať "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru" než "chcem kurací hamburger", to je teda fajn logika. Čitatelnejšie to o nič nieje, a ani to nepotrebuješ. Predsa si hamburger kupuješ ako celok. Obsah hamburgeru zaujíma len zamestnanca mcdonalda, ktorý ale vytvára celistvý "produkt" teda hamburger.
Ne, konzument API samozrejme rika "chci burger".
Ale ta implementace musi byt rozdelena na male kusy, kazdy citelny a kazdy spravne pojmenovany. Aby to pak vypadalo zhrubaKód: [Vybrat]burger =
(horni, dolni) <- houskaNaPul
return Burger(horni, okurka, maso, dolni)
private okurka = ...
private maso = ...
To tvoje je spisKód: [Vybrat]burger =
police <- najdiPolici
housky <- police.prihradky.findFirst(\p -> p.maObrazekHousty)
houstka <- houstky.vemJednu()
if (houstka == NULL) ....
...
...
Pojmenovani jednotlivych casti ma smysl, prestoze nejsou znovupouzitelne. Kdyz to udelas, tak se stane jasne, co se deje (burger je z pulek houstky, okurky a masa), aniz by se musel nekdo prehrabovat v nejakem storadkovem bordelu.
Nemluve o tom, ze ty male pojmenovatelne casti mohou byt napr. samostatne testovatelne (coz muze i nemusi byt dobry napad vyuzit).
i tak je to zbytočné, pretože kód máš zdokumentovaný a máš v ňom komentáre (teda vo vývojovej vetve), samozrejme do produkcie ide čistý kód... takže čitelný je i bez zbytočných "sekaní" metod/funkcií.
Protoze pak neni ta metoda ten chliv, co jsi poslal, ale neco, co se da precist a pochopit.
takže podľa tebe je jednoduchšie povedať "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru" než "chcem kurací hamburger", to je teda fajn logika. Čitatelnejšie to o nič nieje, a ani to nepotrebuješ. Predsa si hamburger kupuješ ako celok. Obsah hamburgeru zaujíma len zamestnanca mcdonalda, ktorý ale vytvára celistvý "produkt" teda hamburger.
burger =
(horni, dolni) <- houskaNaPul
return Burger(horni, okurka, maso, dolni)
private okurka = ...
private maso = ...
burger =
police <- najdiPolici
housky <- police.prihradky.findFirst(\p -> p.maObrazekHousty)
houstka <- houstky.vemJednu()
if (houstka == NULL) ....
...
...
rozhodne nesúhlasím.Aha, takže je to tedy bug. '\0' má numerickou hodnotu nula, takže výsledek return NULL a return '\0' je stejný - vyzkoušej si to. (Pro hnidopichy: je stejný za předpokladu, že makro NULL je definováno jako nula.) Předpokládám, že spíš než return '\0' bylo myšleno return "". Vzhedem k tomu, že ten kód jinak vrací pointer na dynamicky alokovanou paměť by ale i to bylo špatně.CitaceMně teda spíš než pojmenování proměnných vadí ten dvojí způsob zápisu return NULL;, který musí druhý programátor rozluštit a zamyslet se, zda je to bug nebo zamýšlené chování.
čože? ja tam nikde nevidím dvojí způsob zápisu return NULL; Druhý if nieje kontrola na NULL ale na prázdnu hodnotu,... rozdiel:
ne neni to stejný.... ani zdaleka. skus odstraniť overenie na NULL, a predaj ten metóde parameter NULL, nepôjde to.
Zatiaľ čo NULL znamená NULL teda nič. Tak prázdna hodnota znamená že je niekde v pamäti miesto, kde je premenná s prázdnou hodnotou. A '\0' je v podstate zakončenie stringu, ktorá je v C reprezentovaná poľom znakov.Protoze ti to umozni veci pojmenovat.
a čo z toho pomenovania mám? to je jak kdybych si prišiel do mcdonaldu a pomenoval by som každú časť hamburgera ktorý si chem kúpiť... namiesto teda "chcem kurací hamburger" by som povedal "chcem dolnú časť žemle hamburgeru na ňom kurací rezeň, a na ňom hornú časť žemle hamburgeru". Abstrakce k hovnu.
a okrem toho 100+ znakové metódy môžu mať zmysel... na čo je deliť na 2, když samostatne tie 2 metódy nikdy volať nebudeš, ale budeš je chcieť vždy vykonať za sebou? Nehovoriac že sa medzi metódami bude musieť prenášať "medzivýsledok", čož je zbytočne navyše.
príklad z wikipedie:Kód: [Vybrat]def qsort(L):
if L == []:
return []
pivot = L[0]
return (qsort([x for x in L[1:] if x < pivot]) +
[pivot] +
qsort([x for x in L[1:] if x >= pivot]))
len pár riadkov kódu a už mi trvá dobrú sekundu zistiť ťo posledné 3 riadky vlastne predstavujú, a čo všetko pod return patrí. A když by za tím pokračoval kód (teda kdby to nebyl return), a kdyby toho kódu bolo 100 riadkov, tak som totálne z toho... by mi proste trvalo niekoľko sekúnd len pochopiť čo pod čo patrí.
No a to je ešte horšie než end... pretože si pak nemôžem uživateľsky prispôsobiť formátovanie kódu. A okrem toho čo je odsadenie? pojem jasnej, ale z pohladu súboru to niekde sú 2 medzery, niekde 4 medzery, niekde tab, niekde inde zas neco jiného. A najmä miešať kombinácie odsadenia je niečo čo si koleduje o problém, a zas ak by sa nemiešali, no neviem jak by sis zarovnal pod sebe zložitejšie kódy, trebárs už u parametrov funkcií musí to byť docela problém, mať tie parametre rozpísané na viac riadkov. Ak to i samotný jazyk / kompilér vie zhltnúť ok, ale čo uživateľ. Jak rozozná čo je odsadenie/zarovnanie a čo ukončenie nejakého bloku kódu.... proste to je chaos.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
