A helyes inkább ez lehetett volna: "How to write unmaintainable JavaScript code". Néhány megfontolandó és jó tanács mellett olyan borzalmak is bekerültek, mint a beszédes függvénynevek lecserélése valami egykarakteresre. Másutt is rengeteget találkozni ilyen kóddal, így pl.
HashMap hm = new HashMap();
Ó igen? 20 sorral lejjebb már nem fogod tudni mi volt az a hm. Öngyilkosság bevinni ilyesmit a kód fejlesztői változatába, mert amit nyersz a sávszél megtakarításán, azt elveszíted a fejlesztési időn, ami azzal megy el, hogy megértsd és kövesd ezt a módit.
Nem tudom, a srác milyen fat client projekteken dolgozott, de szerény tapasztalatom szerint ezek esetében a kiküldött adat mennyisége a kritikus, attól lesz fat.
Ezzel nem állítom, hogy nem kell optimalizálni, csak azt, hogy nem minden a sávszél megtakarítás.
Felhívja a figyelmet, hogyha máshogy nem, akkor a YUIC-cal tömörítés végett inkább konkatenációval fűzd össze a stringeket, és ne a tömb/push útat kövesd.
Variable declarations at the beginning of the function
Crockford/JSLint ajánlás.
This as local variable
Érthetetlen, hogy miért pont az x-hez köti a this-t, azonban ez még önmagában nem ront az olvashatóságon. Illetve ahogy a következő tanácsoknál is, t.i. nem azt javasolja, hogy az x-hez kösd, hanem hogy a fenntartott kulcsszavak, hosszú elérési láncok, globális elérhetőségű objektumok helyett helyi kötéseket használjunk. A helyi kötés neve viszont – és erre valóban nem tér ki – lehet ugyanúgy beszédes, mert a tömörítő ezt ugyanolyan jól tudja majd egy rövid névre cserélni.
Shorten numbers, Common strings, Repeating access to object members, Shorten object’s member access, Shorten object’s member names
Stringösszefűzés: OK, változódeklaráció: OK, használjunk slot jellegű dolgokat: OK.
A this-t én nem bántanám. Nem azért mert nem lehet, hanem mert a this egyrészt "vezeti a szemet", másrészt konvenció, amit nem feltétlenül érdemes felrúgni csak azért, hogy spórolj néhány bájtot a kódban. PHP-t is írhat az ember, ahogy akar, de mégsem teszi (egy idő után).
Ugyanígy a tagnevek esetében fokozottan, ld. a fenti Java "példakód" esetét.
Az ismétlődő szövegelemek esete annyiban okés, hogy a logika ne tartalmazzon ilyet; vastagkliensnél viszont épp az adat, ami rengeteg ilyent tartalmaz, már ha JSON-t küldesz, amit nem is nagyon lehet kiküszöbölni.
Az én fő szempontom a fenntarthatóság; nem azért, hogy a fejlesztő élvezzen kódolás közben, ami néha nem árt végülis, hanem mert végül súlyos árat kell fizetni a követhetetlen, merev kódért. Ha valaki "egy termék - egy kódhalmaz" körben dolgozik, akkor kevesebb gondja lehet, ha viszont szerteágazó vastagklienses projektekben, amelyeket többféleképp kell/lehet felhasználni, öngyilkosság
Kicsit off: egy másik szempont lehet a debugolás - hogy a jó életbe derítsem ki a munge-olt szövegből, hogy mi is a probléma? Ebből az okból (ha munkahelyen nem is), de másutt csak minify-t használok, ahol azonnal látom, hogy ez és ez a gond, nem kell a fejlesztői kód és a prod kód közötti lehetséges eltéréseken agyalnom.
Összefoglalva: első a fenntarthatóság, utána jön az extrém optimalizálás.
Teljes mértékben elfogadom az álláspontod, de akkor a részedről semmilyen eszköz nem fogadható el, amelyik „rejtjelezi” a kódot. A poszt alap feltevése pedig az volt, hogy ha te ezt akarod, akkor mutatok néhány módszert, miként teheted még hatékonyabbá.
Hibás cím
Nem tudom, a srác milyen fat client projekteken dolgozott, de szerény tapasztalatom szerint ezek esetében a kiküldött adat mennyisége a kritikus, attól lesz fat.
Ezzel nem állítom, hogy nem kell optimalizálni, csak azt, hogy nem minden a sávszél megtakarítás.
Vegyük sorban
Concatenate static strings with +
Felhívja a figyelmet, hogyha máshogy nem, akkor a YUIC-cal tömörítés végett inkább konkatenációval fűzd össze a stringeket, és ne a tömb/push útat kövesd.Variable declarations at the beginning of the function
Crockford/JSLint ajánlás.This as local variable
Érthetetlen, hogy miért pont azx
-hez köti athis
-t, azonban ez még önmagában nem ront az olvashatóságon. Illetve ahogy a következő tanácsoknál is, t.i. nem azt javasolja, hogy azx
-hez kösd, hanem hogy a fenntartott kulcsszavak, hosszú elérési láncok, globális elérhetőségű objektumok helyett helyi kötéseket használjunk. A helyi kötés neve viszont – és erre valóban nem tér ki – lehet ugyanúgy beszédes, mert a tömörítő ezt ugyanolyan jól tudja majd egy rövid névre cserélni.Shorten numbers, Common strings, Repeating access to object members, Shorten object’s member access, Shorten object’s member names
Ld. előző pontban írtakat.Sorban
A this-t én nem bántanám. Nem azért mert nem lehet, hanem mert a this egyrészt "vezeti a szemet", másrészt konvenció, amit nem feltétlenül érdemes felrúgni csak azért, hogy spórolj néhány bájtot a kódban. PHP-t is írhat az ember, ahogy akar, de mégsem teszi (egy idő után).
Ugyanígy a tagnevek esetében fokozottan, ld. a fenti Java "példakód" esetét.
Az ismétlődő szövegelemek esete annyiban okés, hogy a logika ne tartalmazzon ilyet; vastagkliensnél viszont épp az adat, ami rengeteg ilyent tartalmaz, már ha JSON-t küldesz, amit nem is nagyon lehet kiküszöbölni.
Az én fő szempontom a fenntarthatóság; nem azért, hogy a fejlesztő élvezzen kódolás közben, ami néha nem árt végülis, hanem mert végül súlyos árat kell fizetni a követhetetlen, merev kódért. Ha valaki "egy termék - egy kódhalmaz" körben dolgozik, akkor kevesebb gondja lehet, ha viszont szerteágazó vastagklienses projektekben, amelyeket többféleképp kell/lehet felhasználni, öngyilkosság
Kicsit off: egy másik szempont lehet a debugolás - hogy a jó életbe derítsem ki a munge-olt szövegből, hogy mi is a probléma? Ebből az okból (ha munkahelyen nem is), de másutt csak minify-t használok, ahol azonnal látom, hogy ez és ez a gond, nem kell a fejlesztői kód és a prod kód közötti lehetséges eltéréseken agyalnom.
Összefoglalva: első a fenntarthatóság, utána jön az extrém optimalizálás.
Persze senki nem hallgat rám :)
Teljes mértékben elfogadom az
Touché
Szerk.: Ha jól láttam, még nem volt, itt is vannak jópofa tippek a Google háza táján.
Volt (: