@Calculon
Jo, styl a preference. To je jasné a proto, že je to strašně příjemné, vznikají různé coding style nástroje a také různé analyzátory ... není nic lepšího než se po někom hrabav v "osobitém" kódu ... neříkám, čeština v kódu není vražda štěňátek, ale tak česky mluví lidí minimum a i když to tak dnes nemusí vypadat, takový kód už do budoucna vytváří úplně zbytečné omezení v podobě užitého jazyka.
Dokonce možná i zde v článku. Kdyby někdo vygooglil tento článek, bude mít s kódem jazykový problém, zbytečně. Znovupoužitelnost pro jazykové mutace, nazdar. Zrovna ze startu už v první minutě, kdy byl kód napsán ... a jdeme dále. Při jakémkoliv pokusu o další přáci s kódem už musí každý buď transponovat názvy, nebo i ve svém dalším kódu míchat češtinu.
10. 11. 2021, 13:34 editováno autorem komentáře
PS:
... nebo přepsat kód do angličtiny (nebo svého jazyka???, každý ???)
Což mi připomnělo :-D :-D :-D :-D
https://github.com/tkohout/OSTRAJava
10. 11. 2021, 13:36 editováno autorem komentáře
@Pavel Herout
Proč omezovat výukový materiál v nějakém časopise pouze na velmi omezené publikum (jazyk)?
Není to zbytečné omezení hned od prvního písmenka pro jakékoliv jiné čtenáře nebo další jakoukoliv manipulaci kýmkoliv?
A co se pak z takové výuky odnese, návyk psát kód česky?
DISCLAIMER: Pouze se snažím nahlížet z praktického hlediska, nic víc.
10. 11. 2021, 16:18 editováno autorem komentáře
@A.P.Hacker
V porovnani s pracnosti prekladu celeho clanku je preklad tech par slov v kodu malickost.
To je pravda, na druhou stranu si tam do kódu samého začátku zanesete závislost na jazyku čtenáře a potenciální přepisování, což není tak jednoduché, než tam nasekáte chybky - nehledě na to, že by to mohl kdokoliv pochopit i bez toho překladu.
Proč si sám házet potenciální problémy pod nohy, zatímco benefit je ... 0?
(Pokud má někdo programovat a neumí anglicky, God bless him
)
11. 11. 2021, 10:11 editováno autorem komentáře
dat prednost cestine v ceskem clanku na ceskem serveru neznamena neumet anglicky
A on někdo něco takového tvrdil?
To je tak, když porusíte základní pravidlo citace: musíte zachovat kontext. A ten v tomto mluví o výukových materiálech, o těch pro koho jsou určeny a hlavně o tom, že čestina je pouze zbytečna komplikace - protoze kdo chce programovat, prostě musí umět anglicky z podstaty věci - studenty nevyjímaje. Leda v druhé třídě zákl. školy. To není případ témat této série clánků, tedy lituji toho, ldo chce programovat a anglicky neumí.
Dnes je vysekavání textu ze sdělení, a nasledná pranice o textu mimo původní okoli, velmi popularní. Je to v podstatě denní chleba, ale ničemu to neprospívá.
11. 11. 2021, 13:10 editováno autorem komentáře
@A.P.Hacker
Ale jistě, vždy je nejlepší omezit jazykovou dostupnost na velmi malý zlomek vývojářů - a jako má pozmka před tím a ještě před tím, kterou jste dvakrát přehlídl - k čemu je učit se něco v jazyku, ve kterém by to studenti neměli psát?
'
Text okolo, český server? Fajn, z několika důvodů, ale kód ani tak jako ne. V učebnici, dejme tomu, na internetu zbytečné omezení, které je k ničemu.
A jedno vám je to proto, protože většina internetového materiálu okolo programování je od A do Z v angličtině ... proto je vám to jedno.
pro udrzeni ceske terminologie.
Aha. Hodně štěstí s "haldama" ...
troufam si tvrdit, ze po precteni clanku jsem schopny napsat podobny kod s identifikatory v libovolnem jazyce.
Máte pravdu. Bylo by lepší, kdyby víc literatury vznikalo ve španělštině, čínštině, němčině, ruštině ... no co, závorky budou vždy závorky.
Už jenom konstrukce alá
while (česky)
jsou celkem ... divné.
Pouziti cestiny v programovani je proste peklo, omlouvat si to muze kazdy jak chce, ale nic tim nezmeni.
Kazdemu kdo pise kod cesky bych tuze pral, aby se dostal do te situace kdy najde konecne na youtube reseni sveho problemu a cele to tam je spanelsky. Nebo, aby prebral nejaky kod a ten byl psany necim cim se mluvi v Belgii. Ano, tohle jsem oboji potkal a chtel jsem v tu chvili opravdu nekoho skarede mucit. Pokud nekdo nedokaze cist kod anglicky tak nema v IT co pohledavat, at jde prodavat do lidlu.
@Calculon
Nikdy nevíte, kde co najdete a záleží, co řešíte. Např. já se minule nemohl několik hodin doplantat jak různé komponenty konfigurovat ku spolupráci - jako vůbec nějaký užitečný pattern. Specifická věc, žádné články. No a na Youtube se v tom borec "sharescreen" hrabal asi 30 min ... ušetřtil jsem možná i dny ... když pak máte nějako strategii (něčeho co děláte opravdu poprvé), tak hned i víte co chcete v manuálech hledat.
Jak může někdo psát kód v php?
Po dlouhé době v jiných jazycích jsem se zase dostal k projektu v php a upřímně nechápu, proč by v něm (kromě údržby legacy systémů) vlastně někdo měl něco psát. Úplně příšerná základní knihovna s funkcemi vracejícími krásy jako "string|false|0" a k tomu oficiální dokumentace varující před chybným použitím, která následně předvede jako doporučený příklad.
Kdysi snad platila jedoduchost hostingu, ale v dnešní době kontejnerů a cloudových služeb tohle IMHO padá a opravdu mě nenapadá jediný důvod, proč se trápit s tímhle zoufale špatně navrženým jazykem.
@A.P.Hacker
Vznik této série článků má složitější pozadí, které tady nechci vysvětlovat. Pokud by Vás to zajímalo, napište mi e-mail. Ale přímá odpověď - tato série bude ještě pokračovat dalšími dvěma články ohledně základního použití PHPUnit. Další pokračování (mockování v PHPUnit apod.) je sice možné, ale nepravděpodobné. A pokračování v těch nesporně užitečných tématech, které jste nastínil, určitě nebude v časovém horizontu jednoho roku.
Pavel Herout
@wsh
Tipnu si: Closure nebo Rust, náboženská čistota sama co?
"string|false|0"
Toto je úplně normální, takové věci vrací polovina jazyků a má to velké výhody, např. si z možných výsledků v kontextu vykonání funkce můžete vybrat co vás zajímá a co ne, aniž byste musel sám vždy ošetřovat v daném případě všechny variany, které vedou k "string|false|0" - to se hodí speciálně když nepíšete stylem něco tam dám a když se to klientovi pokazí, nějak to spravím až bude čas
(což je dnes velmi moderní).
Já preferuju spíš Python nebo Kotlin, na low-level věci mám dobré reference na ten Rust, ale sám v něm nepíšu.
Používání těch návratových hodnot, co jsem uváděl, místo vyhození výjimky je zhůvěřilost, která vede k tomu, že i konstrukce z oficiální dokumentace hází v phpstan chybu.
Myslím, že o úrovni standardní knihovny php svědčí to, že jednotlivé webové frameworky jako Nette nebo Symfony si dodělávají vlastní wrappery nad věcma jako práce s řetězci nebo poli.
@wsh
Vyjímky nejsou jediný styl jak řídit tok programu, rozhodně to není žádná zhůvěřilost. Např. v C nejsou vyjímky, zhůvěřilost?
Vlastní wrappery se píší všude a pro kde co. Měla by snad PHP SPL obsahovat jakoukoliv možnou funkci nad polem, aby nebyla pod úrovní?
Používání těch návratových hodnot, co jsem uváděl, místo vyhození výjimky je zhůvěřilost, která vede k tomu, že i konstrukce z oficiální dokumentace hází v phpstan chybu.
Byl by konkrétní případ? Já zatím na nic nenarazil.
11. 11. 2021, 21:19 editováno autorem komentáře
https://www.php.net/manual/en/function.preg-match.php
Example #1 Find the string of text "php"
<?php
// The "i" after the pattern delimiter indicates a case-insensitive search
if (preg_match("/php/i", "PHP is the web scripting language of choice.")) {
echo "A match was found.";
} else {
echo "A match was not found.";
}
?>
phpstan: Only booleans are allowed in an if condition, int|false given.
Já to takhle nevymyslel. Jsem zvyklý z Pythonu, že implicitní přetypování se běžně používá a dává smysl (None, 0 a prázdné pole jsou false), ale v php, kde se string obsahující nulu bere jako false (a hlavně lecos se tiše konvertuje na null místo vyhození chyby) chápu, že to linter zakazuje (byť jsem si teď dohledal, že jsou to jen nějaká striktnější pravidla).
Jinak k otázce, zda SPL má obsahovat jakoukoliv možnou funkci - samozřejmě, že ne. Ale měla by obsahovat to, co použije velká část uživatelů a hlavně by ty obsažené funkce měly mít rozumné chování.
Pak by autoři frameworků nemuseli implementovat věci jako Arrays::get - Vrací prvek $array[$key]. Pokud neexistuje, vyhodí buď výjimku Nette\InvalidArgumentException, nebo je-li uveden třetí parametr $default, vrátí ten.
Možná jsem příliš ovlivněný Pythonem i Kotlinem, kdo tohle je samozřejmá součást jazyka, ale nechápu, proč to není v php, buď ve standardní knihovně nebo alespoň v nějaké rozšiřující, kterou ale používají všichni.
https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.null-coalesce-op
$username = $_GET['user'] ?? 'nobody';
ta funkce get byla potreba v dobach, kdy pro to neexistoval operator.
Pokud chci výjimku, když tam ten prvek není?
To ale není nutně to, co všichni chtějí a jak musí jazyk fungovat. Tímto si jenom zanesete do kódu velký blok ošetření vyjímky ... pokud tam není, můžete si ji daleko jednoduššeji vyhodit.
Ostatně, podle best-practice vyjímek, neměl byste vyjímky použitého jazyka, frameworku či balíčků chytat v kódu co nejdříve, aby Váš kód nebyl závislý na implementaci externích zdrojů?
try: return Person( first_name=data["name"], last_name=data["surname"], age=int(data["age"]), ... ) catch KeyError, ValueError: nějaký error handling
PHP reaguje jinak. Toto udělat můžete, odchytí to exceptions. Pro odchytávání errorů se používá
try {} catch (Throwable $t) {}
a set_error_handler() . Ale už vidím, co myslíte. V PHP prostě testujete jestli byl objekt vytvořen, což je to co Vás zajímá v takovém případě. V logu bude něco určitě.
12. 11. 2021, 13:30 editováno autorem komentáře
@wsh
Arrays::get
Věřte nebo ne, za poslední roky jsem si takový handler napsat nemusel. Tím neříkám, že je to zbytečné, na druhou stranu asi nemusí mít každý. Podle mě, kdyby to bylo tak nutné, může vzniknout composer balíček. Pokud vím, není. Možná by moho někdo ;-) nějaký založit
Bohuzel pan je ciste akademik. Kdysi v clancich o testovani jsem mu rikal, ze pojem bila skrinka/cerna skrinka je totalni blbost.
Toto patri pod https://www.root.cz/clanky/jednotkove-testovani-v-php-moznosti-pri-psani-testovacich-pripadu/nazory/1080421/
10. 11. 2021, 20:42 editováno autorem komentáře
@dirka12345
Ano, jsem akademik a nijak se tím netajím. Lidé prostě mají různé profese. Píši výukové (chcete-li akademické ;-)
) články např. do Root.cz s nadějí, že někomu ty informace mohou pomoci.
Pokud zastáváte názor, že v testování jsou pojmy bílá a černá skříňka "totální blbost", pak se určitě neshodneme a nezáleží na tom, zda bych byl z akademické sféry nebo z praxe.
Pavel Herout
@dirka12345
Tak pán už několikrát řekl, že je to pro výukové účely. Já proti tomu sice argumentuji, ale pracovní pohovory bych do toho teda netahal.
Maximálně bych přihodil, že už při výuce by jaksi "student" mohl získávat návyk k jistým vzorům v pojmenovávání v angličtině, speciálně funkcí, ideálně pak takto od zkušeného lektora. To se mu s českými názvy jaksi nepoštěstí.
@dirka12345
Toho bych se nebál. Než dostudují, zabrousí do nespočítaně materiálů mimo český výukový. A nebo nezabrousí a pak práci oprávněně nejspíš nedostanou. Nedovedu si přestavit, že by někdo mohl programovat a neumět anglicky. Teoreticky jistě ano, ale nepřipadne mi to v praxi pravděpodobné.
Osobně proti důrazu na češtinu nic nemám, ale v oblastech literárních a společenských. V technologiích, jak často vidíme, je to takové ... kostrbaté, problematické, obtěžující ... např. skypovat, mailovat ... nebo ... komp či chat a podobně je daleko účelnější, přesnější, pohodlnější a znělejší - tady je někdy potřba lehce ustoupit, čeština to umí.
13. 11. 2021, 16:59 editováno autorem komentáře