A JavaScript, ami tömörödik
A List Aparton megjelent Better JavaScript Minification című cikke folytatásában Nicholas C. Zakas újabb módszereket mutat be JavaScript kódunk tömöríthetőségének javítására.
Első írásában az eval()
függvény és a with
használatának kerülését hangsúlyozta.
A második részben a globális változók, az objektumtulajdonságok és a kulcsszavak érinthetetlenségéből fakadó tetemes elvesztegetett tömörítési potenciál megmentésére vonatkozóan ad hasznos tanácsokat.
A globális változók nem cserélhetők rövidebb nevekre, ugyanis a tömörítő nem tudhatja, azok mely más helyeken kerülnek esetleg felhasználásra. A cél tehát (mely egyébként is követendő szabály), hogy a lehető legkevesebbre csökkentsük a létrehozott globális változók számát, a készen kapottakat pedig azonnal tegyük lokálissá.
function doSomething() {
var doc = document;
// Itt a változó már lokális, tehát a neve rövidíthető
}
Az esetek nagy többségében ha a programunk több részéből is elérhető változóra van szükségünk, akkor sincs igény arra, hogy ezt más programok is elérjék: nem globális, csak a legfelsőbb szintű hatókörben elhelyezett változó kell nekünk. Egy önhívó névtelen függvény tehát ideális a célra:
(function () {
var firstLongVariable, secondLongVariable;
function doSomething() {
// Ő eléri a két változót
}
function doOtherThing() {
// És ő is
}
})()
// Itt viszont már nem érhetők el
Az objektumtulajdonságok esetében hasonló a helyzet, mint a globális változóknál, azok nem rövidíthetők le. A megoldás is ugyanaz: az egynél többször használt kulcsot rendeljük egy helyi változóhoz, ami már biztonságosan átnevezhető a tömörítéskor. Mindig tartsuk észben, hogy ami pont után áll, az nem rövidíthető, így a célunk, hogy a pontok számát a lehető legkisebbre szorítsuk a kódunkban.
Ami a nyelv kulcsszavait illeti, ezek értelemszerűen nem cserélhetők le, így az egyetlen lehetőségünk, hogy eleve csökkentjük a számukat. A var
esetén ezt megtehetjük az összevont deklaráció alkalmazásával.
var firstLongVariable;
var secondLongVariable;
helyett
var firstLongVariable, secondLongVariable;
A másik kulcsszó, melyen spórolhatunk, a return
. Egyes iskolák egyébként is egyetlen visszatérési pontot ismernek csak el, mint üdvözítő gyakorlatot, tömörítési szempontból azonban vitán felül áll ezen tradíció követésének áldásos jellege.
switch (someValue) {
case 'foo':
return 1;
break;
case 'bar':
return 2;
break;
case 'foobar':
return 3;
break;
default:
return 0;
}
sokkal hosszabb kimenetet eredményez, mint
var result = 0;
switch (someValue) {
case 'foo':
result = 1;
break;
case 'bar':
result = 2;
break;
case 'foobar':
result = 3;
break;
}
return result;
A fenti technikák elsajátítása és alkalmazása akkor is jobb programozóvá tesz bennünket, ha nem kívánjuk tömöríteni a kódunkat; ha viszont igen, úgy egy kis odafigyeléssel sávszélességet és tárkapacitást spórolhatunk meg, elhanyagolható ráfordítással. ■
switches példa
Másrészt, nem értem miért tömöríthető jobban a második switch példa,
hiszen az elsőből a break;-ek, a return miatt elhagyhatóak.
Másrészt, nem értem miért
mert a return kulcsszo, igy nem cserelheto le 1 karakteres valtozonevre.
Ez a modszer nem csak switcheknel alkalmazhato, hanem barmely olyan fuggvenyben, ahol van visszateresi ertek. A fuggveny elejen definialsz egy valtozot amit a legvegen returnolsz, a fuggveny belsejeben pedig ennek adod a visszaadni kivant erteket.
a break sem, amit viszont a
legalabbis ezt probalja megertetni a kerdezo, ugy tunik sikertelenul.
a='valtozoHosszusaguErtek';break;
az imho hoszabb, mint a
return 'valtozoHosszusaguErtek';
legalabbis ha az ertek hoszabb mint 2-3 karakter.
es ugye a masodik esetben meg kellene egy
var a;
az elejere, meg egy
return a;
a vegere.
szoval ertem a lenyeget, csak rossz a pelda.
Tyrael
Igen, a pelda a rossz, ezert
Switch tipikusan az, amit nem
Gyakorlat
De igen.
return
zarojelek nelkul (ami a forditonak felesleges, a fejlesztonek nem) hihetetlenul olvashatatlan, es nagyon konnyu benezni.
persze, ahol hashmappel kivalthato, ott konnyu.
de mondjuk egy szokoev-szamito fuggvenyben, amiben az evszambol megmondod, hogy szokoev-e, ott mar nem tudsz hashmap-et csinalni a switch kimeneteleibol.
Tyrael
Js engedi, hogy zárójelek
Teljesen analóg ezzel:
Ha kinyitsz bármilyen refaktorálásos könyvet, akkor kb első rész az, hogy a switch-ben lévő hosszabb részeket külön metódusokba kell tenni. Egyébként ha meg nem szeretnél több metódust, akkor sem jó a switch, mert elhagysz véletlenül egy break-et, aztán borul az egész, akkor már inkább if-else.
Szornyu
Btw., aki egy if -nel az utasitasblokk kore nem rak zarojelet, annak mi kezet-labat torjuk.
Őszintén szólva annyira
Megírtam a map-es változatot is, hátha valakinek nem volt érthető. Ezek után már nem lehet tudni.
tisztaban vagyok vele, hogy
Tyrael
Szerintem sem, szituáció
Köszönöm!
Jogos
Haszon?
És mennyi a sima kód gzippelve és a tömörítő kompatibilissé tett kód gzippelve? Csak mert egy ideje azon a véleményen vagyok, hogy ilyenre akkor maximum akkor van lehetőség, ha egy adott projektre "végtelen sok" idő áll rendelkezésre, gyakorlatban nem mindig van igény erre, maximum nagyon-nagyon-nagy oldalak esetén és általában inkább megéri az olvasható, könnyen karbantartható kódot szem előtt tartani.
nezd meg pl. a jquery
160k vs 70k
http://code.jquery.com/jquery-1.4.2.js
http://code.jquery.com/jquery-1.4.2.min.js
jobb helyeken a js/css minify-olas, osszebuildeles, gzippelest,, css spriteositas, etc. a deploy soran automatikusan megtortenek, szoval a fejlesztoknek csak akkor para a debugolas, ha konkretan ezen eljarasok valamelyike bugos (volt ilyenre is pelda. :P).
en azon az allasponton vagyok, hogy ezt egyszer kell csak jol megcsinalni, aztan automatizalhato, es nagyon megeri, hiszen az oldal renderelesenek nagy resze nem a html oldal letoltese, hanem a dom felepitese, statikus fajlok letoltese, css/jss ertelmezese teszi ki.
Tyrael
Automatizálás vs. odafigyelés
ezzel tisztaban vagyok, sehol
szoval nem igazan ertem, hogy itt most ezt miert irod le nekem.
Tyrael
Kiegészítés
ok, ezzel egyetertek. Tyrael
Tyrael
Nézd meg a cikket
Comment-ezés
Closure Compiler
Viszont ezzel mar ovatosan kell banni ha ADVANCED_OPTIMIZATIONS opciot hasznaljuk, mert komoly valtoztatasokat vegez a kodon.