Názory k článku Programování v JavaFX: kontrola formátu editačních polí

Kdyz uz ten serial nechcete zrusit, mohli byste jej aspon prejmenovat: "JavaFX: 100+1 navod, jak neprogramovat v Jave"

Pouzivani vyjimek pro bezne rizeni programu je zlo! A testovat, jestli je cislo integer nebo double tim, ze ho zkusime zparsovat a pokud to hodi vyjimku, tak to asi nebude cele cislo, je zlo galaktickych rozmeru!

Problemu je tam hned nekolik. Vyjimky jsou zoufale pomale. Autor provadi konverzi cisla z retezce hned 2x. Jednou v metode isDouble() a podruhe Double.valueOf(Strin­g), coz taky nejsou zrovna 2x rychle operace. A vtipne na tom je, ze se da zadat i cislo, ktere neni cislem, tj. NaN.

Autorovi doporucuji nastudovat aspon par kapitol z knihy Effective Java od J. Blocha a priste na neco takoveho pouzit predkompilovany reg. vyraz.

Jakkoliv nechci obhajovat kvality tohoto seriálu, tvůj komentář mi přijde trochu mimo.

- výjimka se zde nepoužívá pro řízení programové logiky, pouze pro parsování čísla
- Výjimky jsou "zoufale pomalé", jen když jsou vrhnuté, a i tak je hlavní část zpomalení v samotném vytváření výjimky (vyplnění stack trace), ne ve vyhazování. Uživateli je navíc asi jedno, jestli kontrola toho, co napsal, potrvá 50 ns nebo 5 μs. Premature optimization is the root of all evil
- Udělat si vlastní parsování čísel pomocí regexů není zas tak jednoduché, a asi ani není cílem učit regexy v seriálu o JavaFX. Navíc se v principu v některých situacích může hodit možnost zapsat veliké číslo jako třeba 1.23E45, což by dále zkomplikovalo regex. V praxi bych stejně asi stejně s regexy nevynalézal kolo, a použil nějakou hotovou knihovnu na parsování čísel.

try {Double.valueOf} mi tedy přijde jako legitimní, jednoduché a funkční řešení pro použití v seriálu, který se nezabývá problematikou parsování čísel. Max. bych v něm uvítal větičku, že to má svoje mouchy. Ovšem vzhledem k tomu, že po všech těch (vcelku oprávněně) nenávistných komentářích se z toho stejně asi nikdo učit nebude, a příspěvky píšou jen ti, co mají chuť si zanadávat, je to stejně nejspíš jedno..

výjimka se zde nepoužívá pro řízení programové logiky, pouze pro parsování čísla

No, a presne to je to rizeni vypoctu.

Výjimky jsou "zoufale pomalé", jen když jsou vrhnuté, a i tak je hlavní část zpomalení v samotném vytváření výjimky (vyplnění stack trace), ne ve vyhazování. Uživateli je navíc asi jedno, jestli kontrola toho, co napsal, potrvá 50 ns nebo 5 μs. Premature optimization is the root of all evil

Nejde mi ani o to, ze je to v tomto pripade zanedbatelne zpomaleni, ale ze je to serial, ktery se snazi ucit neco zacatecniky. A prave v zacatecnickych programech tuto prasarnu vidim temer pravidelne. A pak se lidi divi, ze programy v jave jsou pomale.

try {Double.valueOf} mi tedy přijde jako legitimní, jednoduché a funkční řešení pro použití v seriálu, který se nezabývá problematikou parsování čísel.

Serial se zabyva tolika podruznymi nesmysly, takze regularni vyrazy nebo odkaz na knihovnu, ktera to resi by ho vubec nezabilo.

Ovšem vzhledem k tomu, že po všech těch (vcelku oprávněně) nenávistných komentářích se z toho stejně asi nikdo učit nebude,

A to je dobre. Prave proto je dobre na chyby v serialu upozornovat, aby ctenar/autor vedel, ze nektere veci se daji delat civilizovaneji.

Tak jeste jednou a polopate.

Pokud mas metodu isDouble, ktera interne pouziva vyjimku, melo by u ni v dokumentaci byt: "pokud vraci false, je strasne pomala". V takovem pripade by to asi obstalo. Ale pouziti vyjimek na bezne situace (z pohledu metody isDouble je neciselny vstup bezna zalezitost) je prasarna.

Nicmene, pokud se podivas do kodu, tak je to tam udelano jeste hur.

if (isDouble(...)) {// zavolam si v metode zkusebne Double.valueOf(...)
   x = Double.valueOf(...) // zavolam to znovu.
} else {
   // vypisu chybu
}

Mnohem rozumnejsi by bylo pouzit vyjimky tak, jak se ma, tj. k osetreni vyjimecnych situaci (a ne kvuli jejich vedlejsimu efektu):

try {
   x = Double.valueOf(...) // konverzi provadim prave jednou
} catch (NFE e) {
   // vypisu chybu
}

Je to umělý problém Javy. Všechny normální jazyky na zeměkouli mají už v základu parsovací funkce s výsledkem true/false, nějak takto bool ParseInt(string s, int &output)

Hledáte chyby tam kde nejsou. Kód nikoho nezajímá, takže si kontrolu čísla řešte jak chcete. Navíc u operací, které trvají možná pár nanosekund je fakt opravdu úplně jedno, jestli jich bude 10 nebo 100. Hledáte problémy kde nejsou, nebo respektive pokud Vám to vadí, tak to klidně dělejte správně, ale nebuzerujte ty lidi, kteří si podobnýma nesmyslama nechtějí ztěžovat svoji práci.

Chyby tam jsou, ze ty to nevnimas, je tvuj problem. Pravidelne delam code review a zacinajici programatori podobne prasarny pouzivaji jak na bezicim pasu s vysvetlenim "nasel jsem na internetu, ze se to tak dela". Ze to v tento okamzik neni uplne dulezite nevadi. Zacas se urcite objevi nejaky programator, ktery to pouzije v exponovane casti kodu, a vsichni si budou moci svorne zanadavat, jak je ta Java pomala.

Začínající programátoři dělají mnohem horší věci než že píšou pomalý kód, např. že jejich kód je nesrozumitelný, bez struktury, nerespektuje DRY princip, není otestovaný (ani testovatelný) atd.

Vzal by sis Porsche na Nürbugring? Pravděpodobně ano. Jel bys Porschetem do Globusu udělat nákup pro pětičlennou rodinu? Asi ne... Stejně tak exponovanou část kódu napíšeš optimalizovaně (potom, co si měřením ověříš, že je opravdu exponovaná - to určitě děláš, že? :) ), a tu, u které to je jedno, to napíšeš nejjednodušeji, jak to jde.

Jinak nemá vůbec smysl se bavit o nějaké Javě a high level konstrukcích a můžeme se všichni vrátit k assembleru.

Protoze zacinajici programatori pisou prasacky kod, tak je budeme ucit pomoci prasackeho kodu? Pricemz ten kod jde udelat elegantne i bez praseni a treba i tech reg. vyrazu.

> Pouzivani vyjimek pro bezne rizeni programu je zlo!
ale v jave ina moznost na parsovanie integerov neni

Zrovna pro integery je ta parsovaci funkce naprogramovatelna jednoduse, to by mel kazdy programator zvladnout :) Nerikam pro float/double, to je humus, ale integery...? Dokonce to bude rychlejsi nez ten originalni Integer.parseInt(), protoze ten vola obecnejsi metodu s volitelnym radixem.

v projektoch kde riesite medzikomponentove integracie (= typicka java) je vlastna funkcia pre parsovanie intu na hranici wtf

FYI: Ta uloha, kterou ta metoda resi, neni: "rozparsuj integer", ale "zjisti, jestli je retezec integer".

ok tak ako by to malo vyzerat?

Je to tak tezke precist si celou diskuzi nez zareagujes? Goto...

> Pouzivani vyjimek pro bezne rizeni programu je zlo!

Je to jen kvůli rychlosti nebo máte i jiné důvody?

> Citelnost obvykle dost trpi.

Pokud máte na mysli Javu, není to dáno syntaxí pro chytání výjimek - tj., že v Javě čitelněji zpracujete speciální hodnotu (kterou funkce vrátí, když nastane chyba) než výjimku?

Jsou i situace, kdy výjimky udělají kód čitelnější - viz článek Static exceptions (jazyk OCaml), část Use cases.

Vic nez efektivita mi vadi spatna citelnost kodu.

Dobře a jaká je tedy ta čitelnější varianta?

static Optional<Double> tryParseDouble(d) {
    try {
      return Optional.of(Double.parseDouble(d));
    } catch (NumberFormatException e) {
      return Optional.empty();
    }
}

Anebo "doporučovaný" postup z Javadocu?

final String Digits     = "(\\p{Digit}+)";
final String HexDigits  = "(\\p{XDigit}+)";
// an exponent is 'e' or 'E' followed by an optionally
// signed decimal integer.
final String Exp        = "[eE][+-]?"+Digits;
final String fpRegex    =
    ("[\\x00-\\x20]*"+  // Optional leading "whitespace"
     "[+-]?(" + // Optional sign character
     "NaN|" +           // "NaN" string
     "Infinity|" +      // "Infinity" string

     // A decimal floating-point string representing a finite positive
     // number without a leading sign has at most five basic pieces:
     // Digits . Digits ExponentPart FloatTypeSuffix
     //
     // Since this method allows integer-only strings as input
     // in addition to strings of floating-point literals, the
     // two sub-patterns below are simplifications of the grammar
     // productions from section 3.10.2 of
     // The Java Language Specification.

     // Digits ._opt Digits_opt ExponentPart_opt FloatTypeSuffix_opt
     "((("+Digits+"(\\.)?("+Digits+"?)("+Exp+")?)|"+

     // . Digits ExponentPart_opt FloatTypeSuffix_opt
     "(\\.("+Digits+")("+Exp+")?)|"+

     // Hexadecimal strings
     "((" +
      // 0[xX] HexDigits ._opt BinaryExponent FloatTypeSuffix_opt
      "(0[xX]" + HexDigits + "(\\.)?)|" +

      // 0[xX] HexDigits_opt . HexDigits BinaryExponent FloatTypeSuffix_opt
      "(0[xX]" + HexDigits + "?(\\.)" + HexDigits + ")" +

      ")[pP][+-]?" + Digits + "))" +
     "[fFdD]?))" +
     "[\\x00-\\x20]*");// Optional trailing "whitespace"

if (Pattern.matches(fpRegex, myString))
    Double.valueOf(myString); // Will not throw NumberFormatException
else {
    // Perform suitable alternative action
}

Goto

Seriál sleduji jen kvůli jeho komentářům :))

Fuj to je odporná syntaxe :) Proč devítky a ne třeba sedmičky? Co lomítko v RČ? Co devítimístná RČ? Co dělitelnost 11cti? Umí tohle všechno tahle syntaxe? Pokud ne, co nabízí navíc kromě omezení délky, která by se dala v nějaké fiktivní syntaxi specifikovat rozumněji, třeba

get rodne_cislo 10

?
Tedy jsem rád, že už se takhle věci nedělají. Jinak ovšem např. kamenná sekyrka nebyl vůbec špatný nástroj, viz třeba

http://www.ceskatelevize.cz/ivysilani/1093836883-na-plovarne/211522160100005-na-plovarne-s-jaroslavem-malinou/titulky