« 1 2 3 »
Autor Zpráva
Suta
Profil
shaggy:
Nechci se přít o to, který způsob je lepší. Mnou uvedená verze je, pro mě osobně, oproti tvé "klasické" přehlednější. Jinak počet řádků je něco jiného než-li počet písmen, takže záleží, jakým způsobem chceš vykládat mé "obľúbeného heslo". Nechme však již dohadů.

Právě jsem dodělal modul na přidávání vlastností. Pro informaci, jak funguje, stačí napsat jeden krátký komentář nad daný blok kódu. Díky použitému způsobu mně v kódu nepřekážejí stále opakující se názvy proměnných. Ještě podotknu, že standardní postup používám také, a to v nemalé míře. Následující způsob zápisu používám u specifických operací, jako je např. níže nastíněná funkcionalita. O tom, že by šel kód napsat podstatně úsporněji o obsahuje některé zbytečné průchody vím, nicméně mě tento fakt jakkoliv netrápí (na cílených zařízeních v krajním případě i několik desetin navíc nehraje žádnou roli).

Pokud někdo, kdo používá knihovnu jQuery pro tvorbu složitějších komponent neví, jakou funkčnost má metoda .end() knihovny jQuery, to je pak těžké. To proto, že právě ona (metoda end) je důležitým prvkem, na němž tato knihovna staví, tedy způsob procházení modulu DOM díky řetězení metod. Je-li tedy pravděpodobné, že by na projektu mohl spolupracovat či v budoucnu pracovat někdo, pro něhož by tato skutečnost mohla být problémem, pak souhlasím, že je lepší používat "standardní" nevybočující způsob zápisu zdrojového kódu. To však není můj případ, proto si to mohu dovolit.

else if(propertyEditorId == "saveProperty") {

            var $tr = $target.closest("tr");

            $tr
                .find("input")
                .eq(0)
                .replaceWith(function(){
                    return $(this).val();
                })
                .end()
                .eq(1)
                .replaceWith(function(){
                    return $(this).val();
                })
                .end()
                .end()
                .find("td")
                .eq(2)
                .empty()
                .append("<a propertyEditorId='updateProperty'>Upravit</a>")
                .end()
                .eq(3)
                .empty()
                .append("<a propertyEditorId='deleteProperty'>Odstranit</a>");

            var propertyName =
                    $tr
                        .find("td")
                        .eq(0)
                        .text(),
                propertyValue =
                    $tr
                        .find("td")
                        .eq(1)
                        .text();

                this.actualProperties[propertyName] = propertyValue;

                if(this.onChangeCallback) {
                    this.onChangeCallback(this.actualProperties);
                }
        }
shaggy
Profil
Suta:
Nechci se přít o to, který způsob je lepší.
To sa ani nemusíš, pretože platí to, čo napísal Joker:
Oproti rozdělenému kódu to bude pomalejší o ta dvě volání end().
Tvoj kód je neefektívny. V tomto prípade ide o drobnosť. Pri veľkom plugine a na stránke používajúcej viac pluginov to už môže byť problém.

Pokud někdo, kdo používá knihovnu jQuery pro tvorbu složitějších komponent neví, jakou funkčnost má metoda .end() knihovny jQuery, to je pak těžké.
Prečo? Názov metódy je zavádzajúci, jej funkcionalita je pre mňa zbytočná. Sam vidíš, že pri kóde, ktorý píšem, nič také nepotrebujem.

právě ona (metoda end) je důležitým prvkem, na němž tato knihovna staví, tedy způsob procházení modulu DOM díky řetězení metod.
Ja som si myslel, že dôvodom pre vznik rôznych js frameworkov bolo zefektívniť písanie js kódu a uľahčiť prácu. Ak je metóda end jedným zo základných kameňov, na ktorých jQuery stavia, asi by som sa mal popozerať po niečom inom (aj keď som si istý, že je to iba tvoj názor).

Toto:
.find("input")
                .eq(0)
                .replaceWith(function(){
                    return $(this).val();
                })
                .end()
                .eq(1)
                .replaceWith(function(){
                    return $(this).val();
                })
                .end()
                .end()
                .find("td")
                .eq(2)
                .empty()
                .append("<a propertyEditorId='updateProperty'>Upravit</a>")
                .end()
                .eq(3)
je pre mňa extrémne neprehľadný spôsob zápisu. A bohužiaľ, to množstvo find, end a eq metód je extrémne neefektívne.
Chamurappi
Profil
Reaguji na Sutu:
Pokud vím, tak javascript používá středník pro ukončení příkazu, odsazení řádku pak může sloužit jako formátovací nástroj.
Odřádkování může někdy nahrazovat nepovinný středník. Vynechání středníku u běžně psaného kódu často nepůsobí problém… než na něj pustíš nějaký minifikátor, protože ten obvykle všechno slije do jednoho řádku, který potom kvůli syntaktické chybě nefunguje. Díky minifikátorům jsem si vypěstoval zvýšenou citlivost na neostředníkované řádky.

Kódy, které v dalších příspěvcích uvádíš, mi nepřipadají krásně přehledné, protože není zřejmé, které příkazy se váží k čemu. Možná by mohl pomoct nějaký druh odsazování.
Nejsou ani dobře udržovatelné, protože když si z nich při úpravách omylem odmažeš nějaký .end() nebo prohodíš řádky, bude se chyba špatně hledat. Nejspolehlivější způsob, jak je udržovat, je nešahat na ně. Jinak hrozí, že se rozsypou jako domeček z karet.
Kdybych byl zvýrazňovač kódu, nebyl bych si jistý, jestli ta věc v [#1] je CSS, nebo asembler.

Pokud někdo, kdo používá knihovnu jQuery pro tvorbu složitějších komponent neví, jakou funkčnost má metoda .end() knihovny jQuery, to je pak těžké.
Než jsi se o ní zmínil, netušil jsem, že .end() existuje. Z kódů, které jsi uvedl, jsem vytušil, k čemu slouží, ale na pocitu celkové obskurnosti to nic nezměnilo.


jeden hájí striktnější postupy, na něž je zvyklý, a jiný se nebojí od zaběhnutého způsobu odchýlit
Zkoušíš najít pojítko mezi našimi postoji, abys mohl vše vyřčené označit za záminku a odhalit skutečnou subjektivní příčinu (vítězství zvyku nad kuráží). Proto odvádíš téma ke zřetězování a odřádkovávání. Mohli bychom prosím zůstat u těch prefixů?

Prefixuješ názvy funkcí vracejících jQuery objekt?
Členským proměnným vlastních objektů, které obsahují jQuery, také dáváš na začátky názvů dolar?
Jak často myslíš, že by se ti bez prefixování stávalo, že bys měl proměnnou, u které bys věděl, co s ní chceš dělat, ale nevěděl bys, jestli v ní je jQuery objekt?
Suta
Profil
Reaguji na shaggyho:
Tvoj kód je neefektívny. V tomto prípade ide o drobnosť. Pri veľkom plugine a na stránke používajúcej viac pluginov to už môže byť problém.
Já se nikde netajím tím, že řetězení metod je nejefektivnější řešení, pokud se týče rychlosti. Jelikož vím, v jakých projektech, pro které operace a jakým způsobem si můžu dovolit řetězení (resp. průchod sadou elementů) kombinovat, otázku rychlosti neřeším, jelikož je pro mě nepodstatná. Ušetření několika tisícin či desetin díky klasickému zápisu mi na žádné efektivitě nepřidá, zápis kódu, který je pro mě přehlednější však ano.

Musím podotknout, že zabýval-li by ses do větší míry detailnějšími návody a doporučeními tvůrců jQuery, pak by ses setkal s návrhovými vzory, které (naopak) v určitých případech důrazně doporučují vyhnout se voláním metod jQuery a naopak doporučují využít klasického přístupu k modelu DOM (pro mnoho kritiků jQuery je tento fakt na první pohled zarážející). Použití metody each() v kombinaci se složitějšími průchody a manipulací s několika desítkami či stovkami elementů na stránce může být příkladem. Klasický průchod pomocí for je v tomto případě opodstatněný, jelikož rozdíl v jeho použití a použití metody each() může v závislosti na použitém prohlížeči činit i několika vteřin. Chci tím nastínit skutečnost, že je třeba, aby i programátor využívající jQuery věděl, do jaké míry jej může beztrestně využívat kdekoliv, a kde by měl sáhnout po standardním postupu.

Reaguji na Chamurappiho:
než na něj pustíš nějaký minifikátor, protože ten obvykle všechno slije do jednoho řádku, který potom kvůli syntaktické chybě nefunguje.
Zkoušel jsem jich v praxi několik, některé opravdu slijou kód bez jakéhokoliv ošetření, pak k chybě dojde. Osvědčil se mi http://jscompress.com/, jeden projekt, v němž je na mnoha místech můj způsob formátování, jsem v něm zkomprimoval. Obsahoval i místa, kde středník býti měl, tento konkrétní minifikátor však před komprimací dokázal všechna místa automaticky opravit. Podrobněji jsem od té doby nepátral. Nicméně ano, to riziko, o němž píšeš, zde je.

Prefixuješ názvy funkcí vracejících jQuery objekt?
Členským proměnným vlastních objektů, které obsahují jQuery, také dáváš na začátky názvů dolar?
Ne, tomuto se snažím vyhýbat. Všeobecně pak prefix pro jQuery objekty používám výhradně v lokálním prostoru uvnitř metod a o přeposílání již vytvořených jQuery objektů jinam (argumenty funkcí) neuvažuji.

Jak často myslíš, že by se ti bez prefixování stávalo, že bys měl proměnnou, u které bys věděl, co s ní chceš dělat, ale nevěděl bys, jestli v ní je jQuery objekt?
Těžko říci. Jeden z hlavních důvodů, proč prefix používám je to, že v delším bloku kódu pracuji jak s objekty jQuery, tak standardními elementy modelu DOM. Je-li proměnná s prefixem níže, nemusím rolovat nahoru a dívat se, zda-li se jedná o jQuery objekt či ne. Navíc pro mě není překážkou případná kolize názvů proměnných (target vs $target).
_es
Profil
Suta:
Zkoušel jsem jich v praxi několik, některé opravdu slijou kód bez jakéhokoliv ošetření, pak k chybě dojde.
Okrem toho je riziko, ak sa do toho tvojho špeciálneho formátovania s medzerami, tabulátormi a koncami riadkov zamieša nejaký exotickejší biely znak. A potom nemusí byť problém len s aplikáciami na úpravu kódu, ako rôzne minifikátory, ale aj priamo s prehliadačmi. Napríklad nasledujúci kód v niektorých prehliadačoch funguje, v niektorých nie:
window
 .alert("x")
To síce môže hroziť aj pri normálnejšom spôsobe písania kódu, no v oveľa menšej miere a aj chyba bude oveľa ľahšie odhaliteľná.

Ten podivný kód mi pripomína príkaz with z Visual Basicu: http://msdn.microsoft.com/en-us/library/wc500chb%28v=vs.80%29.aspx
Akurát to je menej zrozumiteľnejšie a udržiavateľnejšie - rozmýšľať nad tým, ako sa to „reťazí“. Ktovie, či to nevzniklo tak, že niekomu takáto syntax toho príkazu v JS chýbala.

nemusím rolovat nahoru a dívat se, zda-li se jedná o jQuery objekt či ne.
Ale to, že ide o premennú „jQuery objekt“ je predsa obvykle jasné z toho, akým spôsobom sa s ňou v kóde pracuje. Ak volám nad premennou metódu mousemove, tak je tam ten špatiaci dolár aj tak nadbytočný.
Suta
Profil
Reaguji na uživatele _es:
Napríklad nasledujúci kód v niektorých prehliadačoch funguje, v niektorých nie:
Nezkoušel jsem, ale věřil bych tomu.

Ale to, že ide o premennú ‚jQuery objekt‘ je predsa obvykle jasné z toho, akým spôsobom sa s ňou v kóde pracuje. Ak volám nad premennou metódu mousemove, tak je tam ten špatiaci dolár aj tak nadbytočný.

To bohužel není pravda. Třeba já používám spoustu vlastních objektů, které obsluhují nativní události, konkrétně používám i tebou zmíněnou metodu mousemove - myProject.mousemove.

Srovnej volání Project.Process.click() v tomto příkladu s voláním $object.click(). Konkrétně na tomto srovnání rozdíl není tak viditelný, pokud si však objekt Project.Process přeuložím do lokální proměnné object, rozdíl mezi voláním object.click a $object.click je markantní.

A to je pouze příklad, vlastních metod, u nichž je název shodný s názvy metod knihovny jQuery mám několik. Pak automaticky neplatí, že vyskytne-li se v kódu volání metody .mousemove, jedná se implicitně o volání metody jQuery. To je jeden z konkrétních příkladů, kde mi prefix pomáhá.
Joker
Profil
Suta:
Pokud někdo, kdo používá knihovnu jQuery pro tvorbu složitějších komponent neví, jakou funkčnost má metoda .end() knihovny jQuery, to je pak těžké.
Tak ono to je i tím, že kdo se drží podobného postoje jako já, metodu end() prakticky nikdy nepoužije.
Protože podle mého názoru přesně na místech kde je end() má nejpozději být středník a pokračovat se dalším příkazem.

Je-li tedy pravděpodobné, že by na projektu mohl spolupracovat či v budoucnu pracovat někdo, pro něhož by tato skutečnost mohla být problémem, pak souhlasím, že je lepší používat "standardní" nevybočující způsob zápisu zdrojového kódu.
Bezva, takže se došli k tomu, že ten kód se hůř udržuje.
Jelikož snadnost údržby se pozná podle toho, kolik lidí je schopných si k tomu sednout a udělat změnu, aniž by se to celé rozsypalo.

Všeobecně pak prefix pro jQuery objekty používám výhradně v lokálním prostoru uvnitř metod
Takže dolar na začátku mají některé instance jQuery objektu a proměnná bez dolaru může pořád být jQuery objekt. Hmm…

v delším bloku kódu pracuji jak s objekty jQuery, tak standardními elementy modelu DOM. Je-li proměnná s prefixem níže, nemusím rolovat nahoru a dívat se, zda-li se jedná o jQuery objekt či ne
Ovšem proměnná bez prefixu pořád může a nemusí být jQuery objekt.
Jinak teda já si nevzpomínám, že bych někdy při psaní kódu zapomněl, co mám v které proměnné (když jsme u toho, blok kódu, který používá tolik proměnných anebo je tak dlouhý, že už zapomínám co je co, je sám o sobě podezřelý).
Daleko spíš chyba vznikne tak, že se do proměnné přiřadí něco jiného, než si myslím že tam mám. Ale proti tomu mi dolar nepomůže (prostě ta špatná hodnota bude v proměnné s dolarem).
A když se později vrátím ke starému kódu, informace, že v proměnné je jQuery objekt mi stejně nebude stačit, potřebuji ještě vědět jaký konkrétně.

S ohledem na ty názvy proměnné mi přijde zajímavá jedna věc: Shlukování operací do jednoho příkazu, jak to prezentuje Suta, de facto odbourává proměnné (zejména proměnné typu jQuery objekt) a nahrazuje je použitím složitějšího příkazu. Mělo by to vést ke složitějším příkazům a menšímu počtu proměnných.
Naopak přístup dělit složitější zápisy na víc příkazů by měl vést k jednodušším příkazům a většímu počtu proměnných.
Dalo by se čekat, že zastánci prvního přístupu nebudou mít potřebu řešit pojmenování těch několika jQuery objektů, zatímco zastánci druhého přístupu naopak budou mít problém s organizací většího množství proměnných.
Ovšem ve skutečnosti to je právě naopak :-)
Suta
Profil
Reaguji na Chamurappiho:
Zkoušíš najít pojítko mezi našimi postoji, abys mohl vše vyřčené označit za záminku a odhalit skutečnou subjektivní příčinu (vítězství zvyku nad kuráží).
Tady nejde o žádnou subjektivní příčinu. Chceš-li objektivně zvážit postup, který si zvolíš, je třeba dát na misku vah jak pozitiva, tak negativa. To já udělal.

Nicméně chyba, kterou jsem udělal, byla hned v úvodu prvotního příspěvku. Tedy v textu "Nauč se využívat uložení odkazu na jQuery objekt do lokální proměnné namísto jeho neustálého vytváření. Proměnné, které značí objekt vytvořený knihovou jQuery pojmenovávej (nepovinná, avšak doporučená konvence) se znakem $ na začátku".

Bohužel jej nyní musím označit za nešťastný. Cítím totiž, žě většina oponentů jej chápe tak, že jej vyzdvihuji nad standardní postup. Tak tomu není. Měl jsem tedy napsat spíše něco na způsob: "Já osobně používám následující postup: (...). Není vhodný pro každého, nicméně mi oproti zaběhlým zvyklostem přináší množství výhod".

Reaguji na Jokera:
podle mého názoru přesně na místech kde je end() má nejpozději být středník a pokračovat se dalším příkazem
S tvrzením nesouhlasím.

Bezva, takže se došli k tomu, že ten kód se hůř udržuje.
K tomu jsi došel ty.

Takže dolar na začátku mají některé instance jQuery objektu a proměnná bez dolaru může pořád být jQuery objekt.
Čerpáš odkud? Dolar na začátku mají všechny instance jQuery, proměnná bez dolaru není jQuery objekt. Pokud chce někdo aplikovat prefix pro jQuery objekt, pak toto pravidlo musí dodržet na všech místech.

Ovšem proměnná bez prefixu pořád může a nemusí být jQuery objekt.
Vážně jsem v žádném z předchozích příspěvků nepsal, že proměnná s prefixem $ je vždy! jQuery objekt, a to bez výjimky?
Joker
Profil
Suta:
Dolar na začátku mají všechny instance jQuery, proměnná bez dolaru není jQuery objekt. Pokud chce někdo aplikovat prefix pro jQuery objekt, pak toto pravidlo musí dodržet na všech místech.
Aha. Ovšem podle věty:
Všeobecně pak prefix pro jQuery objekty používám výhradně v lokálním prostoru uvnitř metod a o přeposílání již vytvořených jQuery objektů jinam (argumenty funkcí) neuvažuji.
pak taková konvence neumožňuje, aby jQuery objekt byl vstupem nebo výstupem nějaké metody.
Suta
Profil
Reaguji na Jokera:
pak taková konvence neumožňuje, aby jQuery objekt byl vstupem nebo výstupem nějaké metody.
Přesně tak. V průběhu jsem již dvakrát psal, že tomuto se vyhýbám. jQuery objekt zásadně nikdy nikam "nepřeposílám".
Joker
Profil
Suta:
Začíná mi to zapadat do sebe („máš-li v kódu desetitisíce řádků a v každém bloku kódu používáš jak běžné proměnné (různých typů), tak proměnné, v nichž máš uloženy objekty jQuery“, „proč prefix používám je to, že v delším bloku kódu pracuji jak s objekty jQuery, tak standardními elementy modelu DOM“, „jQuery objekt zásadně nikdy nikam "nepřeposílám".“)
Ale čím dál víc se utvrzuji v tom, že to vede k tvorbě nepřehledného kódu.

Získal jsem z toho asi takovou představu: Kód dělený na relativně málo velmi rozsáhlých bloků (proto se tam ztrácejí významy proměnných), které jsou samy tvořeny relativně malým počtem velmi složitých příkazů.

Jestli to tak je, tak chápu, proč jsem to nechápal. Moje představa o přehledném kódu je spíš opačná: Větší počet krátkých bloků (jakýkoliv kód použitelný opakovaně je metoda něčeho) tvořených pokud možno jednoduchými snadno pochopitelnými příkazy.
Suta
Profil
Joker, ostatní diskutující:
Přidám aktuální myšlenku, zda-li vůbec někdo z vás používá či někdy použil ve svém kódu (v rámci jednoho bloku) kombinaci jQuery objektu a elementu DOM?

Reaguji na Jokera:
Moje představa o přehledném kódu je spíš opačná: Větší počet krátkých bloků (jakýkoliv kód použitelný opakovaně je metoda něčeho) tvořených pokud možno jednoduchými snadno pochopitelnými příkazy.
Této představě rozumím a souhlasím s ní. Překvapivé pro tebe bude, když řeknu, že s mým kódem není v kolizi. Pokud projekt nabude širších rozměrů, neobejdeš se bez "minifikace" (myšleno sbalení bloků) zdrojového kódu přímo v editoru, v němž kód píšeš. Alespoň já ne.

Nevím, zda-li používáš shlukování bloků kódu, resp. máš-li takový editor k dispozici (já používám Intellij Idea, ale umí to např. Eclipse). Pokud si níže uvedený kód otevřeš celý "v jednom kuse", pak délka určitých bloků kódu může přesahovat míru přehlednosti. Rozhraní, které umí bloky sbalit/rozbalit však naopak přehlednost zaručí, takže v mém editoru vypadá kód následovně (viz foto níže). Nechám na tvém zvážení, zda-li je pro tebe tento zápis stále "nepřehledný".

Srovnej tento kód (řádky 272-383)

a řádky 272-383 na obrázku níže:
Joker
Profil
Suta:
Přidám aktuální myšlenku, zda-li vůbec někdo z vás používá či někdy použil ve svém kódu (v rámci jednoho bloku) kombinaci jQuery objektu a elementu DOM?
Tak samotné např. $(…)[0] je obojí, na jiný případ si nevzpomínám, možná použil, ale nijak často.

Ohledně přidané části:
Mno, po proměnné jménem This mi opravdu $this nepřipadá tak hrozné :-)
Jinak teda řádek 383:
[0];
jako dokončení příkazu započatého na řádku 257 mi taky přijde kouzelný.
No a přijde mi, že by to celé šlo nahradit nějakou konstantou plus innerHTML.
joe
Profil
_es:
To máš potom tú ‚jQuery premennú‘ označenú dvakrát - aj prefixom aj v dokumentačnom komentáre. Na čo?
Jen jednou přeci, bavíme-li se o názvu proměnných. Komentování kódu je zase jiná věc. Důležité je, že uvnitř funkce vím, co je jQuery proměnná, pokud s parametrem někde pracuji.

No ale to je z hľadiska výkonu aplikácie nepriaznivé.
Tak do hloubky JavaScript neznám, ale hádám že to bude podobné jako s funkcionálním VS objektovým programováním i v jiných jazycích. Nijak jsem to netestoval, ale nevidím nic špatného na tom, vyhodit vyjímku při chybě - skript skončí, pokud není zachycená.

Okrem toho aj výraz this môže obsahovať ‚jQuery objekt‘.
Může, pak zase platí ono pravidlo var $this = this; :-)

Na čo si dopredu vytvárať také nepraktické obmedzenie? To sa snáď nedá vymyslieť funkcia, ktorá by nejako užitočne pracovala s ‚jQuery objektmi‘ aj s ‚nejQuery‘ objektmi?
Nejspíš máš na mysli to, že v proměnné může být "klasický" element, v případě že chci jQuery, není problém si ho převést.
Já to myslel tak, že proměnná bude null, tzn. že nebude vůbec nastavená, ani na žádný element.



shaggy:
A vysvetlíš mi, ako tomu zabráni použitie dolára v názve premennej? Ak je to vstup, ktorý sa nevytvára v rámci tvojho kódu a vkladá ho niekto iný, tak by si mal kontrolovať vždy, nie? Dolár na tom nič nezmení.
Pokud se kód pro veřejnost, kontrolovat by se to mělo vždy. Pokud mám kód pod kontrolou sám, moc proměnné nekontroluju, i když vím že to není nejlepší způsob, "stačí" abych si okomentoval parametr metody komentářem a vím, co mohu vkládat a co ne. Dolar mi pomůže s tím, že hned vidím, že mohu volat funkce z jQuery.

Chamurappi:
Ale co s ní ten člověk chce dělat, když vůbec neví, co v ní je? Neměl by na ní šahat, pokud netuší, k čemu slouží.
:-) Člověk se dozví z názvu co v proměnné je, jestli má před sebou $, pak si může s jejím "obsahem" lehce animovat a nemusí ho dál nic trápit.

Array je mnohem častěji používaný objekt a neprefixuje se.
Ale pole je součástí JavaScriptu, jQuery je "rozšíření".

Joker:
Stále nechápu proč.
Pro přehlednost, nejenom mně to přijde přehledné a rychle napovídající co s proměnnou mohu a nemohu dělat.

V případě jQuery je to ještě navíc komplikované tím, že dolar je pro název proměnné neobvyklý znak, takže spoustě lidí nedojde, že $ je vlastně název proměnné.
Nikoho nenutím aby prefixoval své jQuery proměnné dolarem, ale doporučuji to. Dle mého to zpřehlední kód a nenutí vymýšlet další názvy proměnných.

Příklad:

var body = document.body,
      $body = $(body);
      
...
body.className = body.className.trim() + " js"; // zde jQuery nepotřebuji
...

if ($body.hasClass("...")) { // zde už ho ale využiji, dolar mi jasně říká, že mohu použít funkci hasClass

}
      

Pokud bych psal
if (body.hasClass("...")) { // 

}
musel bych přemýšlet a zjišťovat, co v proměnné mám uložené. Pokud jen pouze element a nebo element obalený jQuery. V prvním případě bych skončil chybou, ihned bych se ji dozvěděl při pokusu o načtení stránky, ale kam bych pak ukládal pouze referenci na document.body, když proměnnou body mám již zabranou jQuery objektem. Proto ten dolar, jako výhodu vidím:

- přehlednost, hned rozeznám co je a co není jQuery objekt
- nemusím vymýšlet další názvy jinak prefixovaných nebo sufixovaných proměnných (schválně, jak byste to kdo pojmenoval, pokud se mi nechce všude psát document.body)
- jeden znak navíc, který mně osobně pomůže

[#1] Suta

Musím napsat, že číst takový kód, tak snad zešedivím :-) Když pominu onu vytýkanou efektivitu v řádu setin nebo ještě nižších jednotek, kód je pro mě velmi nepřehledný a než při jeho čtení dojdu ke ;, zapomenu co to má vlastně dělat a s jakými elementy. Zde by se hodily proměnné, ať už s $ nebo bez něj.
_es
Profil
Suta:
proměnná bez dolaru není jQuery objekt
Argument funkcie je lokálna premenná tej funkcie. Teda ak tvrdíš, že argumentom funkcií prefix nedávaš a boli by to jQuery objekty, tak tam premenné bez doláru obsahujúce jQuery objekt budú. Či už ako lokálne premenné samotnej funkcie, alebo prípadných obaľujúcich funkcií.

jQuery objekt zásadně nikdy nikam "nepřeposílám".
To ako vytváraš všetky funkcie a metódy len tak, aby nemohli mať ako argument „jQuery objekt“? To je akosi dosť obmedzujúce. To „nepreposielanie“ znamená čo všetko? Ani v príkaze return nemôže byť jQuery objekt? To je tiež nejaké „preposielanie“.

joe:
nevidím nic špatného na tom, vyhodit vyjímku při chybě - skript skončí, pokud není zachycená.
Ale na to tvoje „vyhodenie výnimky“ treba vykonať kód navyše - a to vždy, teda je vykonávanie kódu menej efektívne.

Může, pak zase platí ono pravidlo var $this = this; :-)
To naozaj vytváraš nadbytočnú premennú len preto, aby mala v názve dolár?

if ($body.hasClass("...")) { // zde už ho ale využiji, dolar mi jasně říká, že mohu použít funkci hasClass
Funkcie a metódy tiež prefixuješ dolárom, aby si z kódu $f().hasClass("...") či objekt.$metóda().hasClass("...") videl, že „môžeš použiť funkciu hasClass“?

Nejspíš máš na mysli to, že v proměnné může být "klasický" element, v případě že chci jQuery, není problém si ho převést.
Nie, myslel som funkciu, ktorá by pracovala aj s Jquery objektmi aj s nejakými inými objektmi či inými dátovými typmi.

proměnná bude null, tzn. že nebude vůbec nastavená
„Nenastavená“ premenná má hodnotu undefined.
Suta
Profil
Reaguji na uživatele _es:
Teda ak tvrdíš, že argumentom funkcií prefix nedávaš a boli by to jQuery objekty“ (...)
To ako vytváraš všetky funkcie a metódy len tak, aby nemohli mať ako argument ‚jQuery objekt‘?
Ano, jQuery objekty v kombinaci s argumenty funkcí nepoužívám.
_es
Profil
Suta:
jQuery objekty v kombinaci s argumenty funkcí nepoužívám.
A to potom ako splníš úlohu typu „S viacerými objektami jQuery niečo vykonaj!“ tak, aby to bolo možné vykonať opakovane s rôznymi objektmi?
Suta
Profil
Reaguji na uživatele _es:
Chci-li pracovat s objektem jQuery, pak téměř vždy přijímám element DOM, který na objekt jQuery převedu.
joe
Profil
_es:
Ale na to tvoje ‚vyhodenie výnimky‘ treba vykonať kód navyše - a to vždy, teda je vykonávanie kódu menej efektívne.
Jistě, to je jako kdybys psal, že na namazání chleba potřebuju nůž.
V objektovém programování jsou vyjímky docela běžnou záležitostí nebo ti přijdou i tam zbytečné, protože vykonávání kódu je pak méně efektivní?

To naozaj vytváraš nadbytočnú premennú len preto, aby mala v názve dolár?
Důvod proč nevytvářet? Vytvářím tak referenci, tedy alias a pokud mi to zjednoduší nebo zpřehlední kód, tak je to jedině plus.

Funkcie a metódy tiež prefixuješ dolárom, aby si z kódu $f().hasClass("...") či objekt.$metóda().hasClass("...") videl, že ‚môžeš použiť funkciu hasClass‘?
Ne, protože vím, že jQuery používá fluent interface a pokud si výsledek neukládám do proměnné, je v tomto případě zbytečné prefixovat názvy funkcí, protože pokud dostávám kolekci elementů, budou téměř vždy obaleny jQuery.

Pokud tedy chci ukládat výsledek do proměnné, prefixuji:

var $items = $("items"),
  $parent = $items.parent(),
  parentWidth = $parent.width();

Nie, myslel som funkciu, ktorá by pracovala aj s Jquery objektmi aj s nejakými inými objektmi či inými dátovými typmi.
To je v mém případě tak málo ojedinělé, že jsem nad tím nepřemýšlel :-)

‚Nenastavená‘ premenná má hodnotu undefined.
Pokud si definuju proměnnou, nastavuju ji na null, psát undefined mi přijde dlouhé a zbytečné, ale možná že se to k něčemu (kromě ověřování, zda proměnná existuje) hodí.
_es
Profil
Suta:
Chci-li pracovat s objektem jQuery, pak téměř vždy přijímám element DOM, který na objekt jQuery převedu.
Teda aby si mohol pracovať s objektom jQuery ako vstupným argumentom, tak s neho najprv vyrobíš objekt DOM a potom zase z objektu DOM vyrobíš objekt jQuery. To je teda naozaj „efektivita“ a „zjednodušenie“ kódu. A čo spravíš, ak by mal byť vstupným argumentom objekt jQuery predstavujúci viac elementov? To by sa to „preposielanie“ nejako skomplikovalo.

joe:
Vysvetleniu s „fluent interface“ a kolekciou elementov akosi vôbec nerozumiem. Aký je rozdiel v neznalosti typu hodnoty v premennej a v návratovej hodnote funkcie? Aký „interface“ používa jQuery je jedno, ja som sa pýtal o vlastných funkciách a metódach vlastných objektov.

Pokud si definuju proměnnou, nastavuju ji na null
No ale to už nie je „nenastavená“.

psát undefined mi přijde dlouhé a zbytečné
Netreba tam predsa písať nič, stačí var premenná; a hodnota premennej bude undefined automaticky - jedine, že by bola definovaná opakovane.
joe
Profil
_es:
Aký je rozdiel v neznalosti typu hodnoty v premennej a v návratovej hodnote funkcie?
Tím, že si proměnnou označím s dolarem, tak už vím, že tam bude jQuery. Pokud si výsledek funkce nikam neukládám, nevidím důvod prefixovat cokoli.

No ale to už nie je ‚nenastavená‘.
Netreba tam predsa písať nič, stačí var premenná; a hodnota premennej bude undefined automaticky - jedine, že by bola definovaná opakovane.
Ano, ale už ze zvyku se snažím používat kde to jde typové porovnání.

místo kódu
var promenna;
...

if (!promenna)

bych psal if (promenna === undefined) // timto zapisem si nejsem moc jisty, jestli to nevyzaduje typeof promenna === "undefined", proto raději nastavím na null, ale protože v jiných jazycích se používá null, raději si napíšu
var promenna = null;
if (promenna === null) {}
Suta
Profil
Reaguji na uživatele joe:
Je dobrý zvykem nastavovat hodnotu undefined u proměnných, u nichž předem neznáš jejich budoucí hodnotu. Naopak proměnné, které víš, že budeš plnit (např. objektem), nastavovat na hodnotu null.

Hájím smysl aplikovat prefix pro jQuery objekty, jsem příznivcem dobrých důvodů pro zachytávání výjimek, nicméně... Nezlob se na mě za použité přirovnání, ale aplikace výjimek v kombinaci s kontrolou jQuery objektu tak, jak ji popisuješ zde a rozvíjení myšlenky v několika následujících příspěvcích je neskutečná pitomost.
joe
Profil
Suta:
Je dobrý zvykem nastavovat hodnotu undefined u proměnných, u nichž předem neznáš jejich budoucí hodnotu.
Snad téměř vždy znám budoucí hodnotu. Zatím jsem se nesetkal s tím, že bych to nevěděl, ale věřím, že stát se to může a nebo si nevzpomínám na ten případ, kdy tomu tak bylo.

aplikace výjimek v kombinaci s kontrolou jQuery... je neskutečná pitomost
Když koukám co jsem tam napsal, tak s tebou souhlasím, asi to je pitomost. Ale na druhou stranu, opravdu se mi chce psát do každé funkce, která přijímá jako parametr jQuery objekt (a má to i napsané v komentáři nad ní) zjišťování, jestli se skutečně jedná o jQuery objekt? A co bych měl udělat, když bych jQuery nedostal? Převést? Může to totiž nadělat víc škod, než užitku:

funkcePrijmajicijQuery (item) {
  if (!item) throw "Neni item";
  if (!(item instanceof jQuery)) {
      item = $(item);
  }
}

$("#items .item").each(function () {
    var item = $(this);
    this.title = "nějaký titulek";
    funkcePrijmajicijQuery(this); // omylem funkci zavolam misto s item s this, vse bude fungovat, ale pokud bude celkovych iteraci 1000, namisto 1000 jQuery objektu jich vytvorim 2000 a nikdo me o tom neupozorni
});

Je to opravdu to, co chci? Neodhalí mi vyjímka, kterou jsem napsal v tebou odkazovaném kódu chybu, kterou bych jinak hledal třeba hodně dlouho?
Joker
Profil
joe:
Ta metodika s null se trochu podobá tomu prefixování dolarem, jen to je ještě horší.
Stejně jako u dolaru: Nestává se mi, že bych zapomněl, pro co jsem si vytvořil proměnnou. Při psaní kódu nemám problém si pamatovat, že proměnnou XY jsem vytvořil pro jQuery objekt a do proměnné YZ jsem ještě nic nepřiřadil. Když se ke kódu vracím třeba po půl roce, stejně si projdu, co vlastně dělá. Pro jistotu.
Stejně jako u toho jQuery objektu i tady je obvykle problémem situace, kdy výsledkem nějakého výrazu je něco jiného než já očekávám. A to potřebuji testovat.

V první řadě proč tam vlastně dávat zrovna null? To si tam můžu dát rovnou false a psát jen if(!promenna).
Každopádně, dám příklad:
var foo = null;
if(typeof(mujObjekt) == "object" ) foo = mujObjekt.bar;
Hodnota proměnné foo může být:
- hodnota mujObjekt.bar, pokud toto je nastaveno
- undefined, pokud mám mujObjekt, ale nemá nastaven atribut bar
- null, pokud nemám mujObjekt.

Kdyby tam bylo jen var foo;, bude v ní buď hodnota, nebo undefined. Čili tím přiřazováním null se nezbavím hodnoty undefined, ale naopak si vytvořím ještě jednu možnost navíc.
_es
Profil
joe:
Premenné:
Podmienka if(!premenná) funguje, ak je premenná undefined aj keď je null.

protože v jiných jazycích se používá null, raději si napíšu
To je teda zdôvodnenie. Treba písať podľa toho, v akom jazyku sa programuje.

A co bych měl udělat, když bych jQuery nedostal? Převést?
Prečo by si to mal prevádzať? Predsa ak je v dokumentácii k funkcii napísané, že to má byť jQuery objekt a niekto tam dá niečo iné, tak to je jeho chyba. Výnimky treba používať nejako rozumne, nie tak, aby všade všetko kontrolovali.
Joker
Profil
_es:
Neodsuzoval bych obecně vyhození výjimky při neplatném argumentu metody.
Třeba v C# existuje přímo k tomu určený typ výjimky.

Podle mě záleží na povaze té metody. Když ta metoda třeba porovnává, jestli vstup odpovídá nějakým podmínkám, není problém na null, undefined apod. reagovat jednoduše např. return false;. Ale když metoda je navržená tak, že něco převezme, něco s tím udělá a očekává se, že třeba vždycky vrátí určitý objekt, tak co by při neplatném vstupu měla udělat?
_es
Profil
Joker:
Ani v kóde jQuery nepoužívajú (vždy) výnimky na kontrolu argumentov: jQuery object is null

co by při neplatném vstupu měla udělat?
Buď sa výnimka „vyhodí“ aj tak, v dôsledku inej chyby - tak ako v odkázanom vlákne, alebo jednoducho funkcia nepracuje správne. Je to cena za ušetrenie kódu a jeho zrýchlenie.
joe
Profil
Joker:
Ta metodika s null se trochu podobá tomu prefixování dolarem, jen to je ještě horší.
Důvod?

Při psaní kódu nemám problém si pamatovat
Při psaní kódu "neexistuje" nic jako žádný problém se zapamatováním. S kódem může pracovat více lidí.

Když se ke kódu vracím třeba po půl roce, stejně si projdu, co vlastně dělá. Pro jistotu.
Možná kdybys měl nějaký systém, nemusel bys ho tolik procházet ;-)

V první řadě proč tam vlastně dávat zrovna null?
Protože v ní nic není? Je prázdná, proto je null / nulová / nic v ní není :-) Používám jen v případech ve spojení s objekty.

To si tam můžu dát rovnou false
true / false je jak všichni víme buď pravda a nebo nepravda, nic jiného nebo mezi neexistuje. Z toho důvodu se mi nelíbí, abych si řekl, že proměnná je buď objekt a nebo false. Nejde mi to k sobě.

Každopádně, dám příklad:
Kdyby tam bylo jen var foo;, bude v ní buď hodnota, nebo undefined.
Ano, máš pravdu, ale ten příklad se mi moc nelíbí a chybí mi tam jedna podmínka, která by do tebou uvedeného stavu proměnnou nikdy nedostala:
if(typeof(mujObjekt) === "object" && typeof(mujObjekt.bar) !== "undefined") foo = mujObjekt.bar;
Pak mám opět buď null a nebo proměnnou nastavenou (objektem).

_es:
Podmienka if(!premenná) funguje, ak je premenná undefined aj keď je null.
Vím, to mě ale nenutí používat právě undefined.

To je teda zdôvodnenie. Treba písať podľa toho, v akom jazyku sa programuje.
Třeba si každý jazyk trochu "poupravit", aby se v něm člověku lépe pracovalo :-)

Pokud deklaruju objekt, (pravděpodobně) musím jeho vlastnosti i definovat, pokud chci použít tento zápis:
var obj = {
    p1: "...",
    p2, // tady musím vlastnost objektu definovat, proč bych měl definovat na "undefined", když ji definuji? To nedává smysl, napíšu tedy:
    p2: null,
    p3: "..."
};

Prečo by si to mal prevádzať?
Protože je dobré kontrolovat vstupy, můžeš (ale i nemusíš) se tak vyhnout případným problémům v budoucnu.

---

Abych se vrátil zpět k původnímu tématu prefixování proměnných dolarem. Pokud tedy nechcete prefixovat proměnné, jakým způsobem pak např.:

převedete objekt Window na objekt jQuery, abyste si zachovali obě reference, protože vytváření více jQuery objektů na již jednou vytvořené je zbytečné.

S použitím $ na začátku zachovám čistotu kódu, bez prefixu si nevím rady, těším se na ně od vás :-)
_es
Profil
joe:
Protože v ní nic není? Je prázdná, proto je null / nulová / nic v ní není :-) Používám jen v případech ve spojení s objekty.
Je v nej hodnota null, prázdna nie je. A „nenastavená“ premenná „nespojená“ s objektmi má mať hodnotu akú? Alebo taká, ktorá môže s objektmi byť „spojená“ aj „nespojená“?

tady musím vlastnost objektu definovat, proč bych měl definovat na "undefined", když ji definuji? To nedává smysl, napíšu tedy:
Aký veľký zmysel dáva hodnota null voči hodnote undefined?

akým způsobem pak např.:
převedete objekt Window na objekt jQuery, abyste si zachovali obě reference, protože vytváření více jQuery objektů na již jednou vytvořené je zbytečné.
Použijem dve premenné, vhodne nazvané, trebárs aj podľa tej podivnej konvencie - v tomto konkrétnom prípade to dáva aj trochu praktický zmysel.
joe
Profil
_es:
prázdna nie je
"Prázdná" je, protože je v ní null a to znamená nulová. S objekty to má takovou souvislost, protože pokud je null, jedná se o objekt:
typeof(null) === "object" // je pravda (opraveno)

Aký veľký zmysel dáva hodnota null voči hodnote undefined?
Když to přeložíme:
null - nulová hodnota
undefined - nedefinovaná hodnota

Nebudu přeci nastavovat proměnné nedefinovanou hodnotu, když ji definuji :-)

Použijem dve premenné, vhodne nazvané, trebárs aj podľa tej podivnej konvencie - v tomto konkrétnom prípade to dáva aj trochu praktický zmysel.
Takže v tomto případě třeba zavedeš prefix dolar a v jiných ne? To mi také nezní moc logicky. Proč dělat vyjímky jen v tomto případě?

Pokud nepoužiješ prefix dolaru, jaký název zvolíš tak, aby bylo jasné co je originální objekt Window a co je obalený objekt Window funkcí jQuery?
« 1 2 3 »

Vaše odpověď

Mohlo by se hodit

Neumíte-li správně určit příčinu chyby, vkládejte odkazy na živé ukázky.
Užíváte-li nějakou cizí knihovnu, ukažte odpovídajícím, kde jste ji vzali.

Užitečné odkazy:

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0