JavaScript – podstawowe błędy #1

Czasem ludzie pytają mnie – przede wszystkim mailowo – o ocenę ich kodu lub zaproponowanie rozwiązania. W większości podczas analizy problemów przejawia się pewien kanon błędów, jakie popełniają początkujący programiści. Postanowiłem więc wyselekcjonować kilka z nich i opisać ku przestrodze.

new Array

var a = new Array(); // ŹLE
var a = []; // DOBRZE 

Przykład stary jak świat, ale wart piętnowania. new Array jest wolniejsze (bo wywołujemy konstruktor Array) oraz mniej bezpieczne:

var Array = 1;
var a = new Array(); // boom!

function mojaFunkcja () {}

function zrob () {};
function poczekaj () {};
function costamInnego () {};

Wielu ludzi wkleja coś takiego do <script /> i ma w nosie wszystko dookoła. W ten sposób zanieczyszczamy globalną przestrzeń nazw i generalnie brudzimy w kodzie. Można uniknąć tego poprzez jako taką imitację przestrzeni nazw:

var Lib = {
	zrob : function () {},
	poczekaj : function () {},
	costamInnego : function () {}
};

Lib.zrob();

Co do namespacingu polecam ciekawy artykuł, który przedstawia nieco inny punkt widzenia, ale warto go rozważyć.

Drugi częsty błąd:

var fn = function foobar () {};

W IE coś takiego powoduje wyciek zmiennej foobar jako globalnej.

el.setAttribute(„style”, „font-weight: bold”)

Wolna metoda na ustawianie stylów i dość nienaturalna. Nie działa w IE. Zamiast tego:

var el = document.getElementById("elem");
el.style.fontWeight = "bold";

Warto też powiedzieć, że o wiele lepiej sprawdza się nadanie klasy, zamiast ustawiania kilku stylów naraz. Zamiast:

var el = document.getElementById("elem");
el.style.fontWeight = "bold";
el.style.fontStyle = "italic";
el.style.display = "block";

zrób tak:

.special {
	font-style: italic;
	font-weight: bold;
	display: block;
}
var el = document.getElementById("elem");
el.className = "special";

Przy okazji, jeśli chcesz sprawdzić, czy element zawiera już podaną klasę, w nowych przeglądarkach implementowane jest powoli classList:

var name = "special";
if (el.classList.contains(name)) {
// klasa istnieje
}

something = true

Pamiętajcie o var! W powyższy sposób deklarujecie zmienne globalne!

something = true; // ŹLE
var something = true; // DOBRZE

el.onclick = function () {};

Pamiętajmy o poprawnym modelu W3C do dodawania zdarzeń, a więc:

el.addEventListener("click", function () {}, false);

W IE:

el.attachEvent('onclick', function () {});

document.getElementsByTagName

Nie jest to zarzut, aczkolwiek nowsze przeglądarki implementują coś, dzięki czemu możesz zapomnieć o jQuery tj. document.querySelectorAll:

var specials = document.querySelectorAll("#wrapper .special");

new Image

Uwaga, można nadpisać!

var Image = "hej Sokoły!";
var img = new Image(); // boom!

Lepiej oprzeć się na DOM:

var img = document.createElement("img");
img.src = "http://something.com/something.jpg";

parseInt(„08”)

parseInt("08"); // 0

Pamiętajmy o systemie liczbowym do jakiego chcemy konwertować stringa!

parseInt("08", 10); // 8

hasOwnProperty

Do czego służy hasOwnProperty?

Object.prototype.somethingMine = function () {};
var o = { foo : "bar" };

for (var i in o) {
	if (o.hasOwnProperty(i)) {
	}
}

Jeśli nie zawrzemy powyższego warunku, przeiterujemy też wraz z somethingMine.

undefined

foo === undefined; // ŹLE
typeof foo === "undefined"; // DOBRZE

Pamiętajmy, że można łatwo nadpisać undefined:

var undefined = 1;

Sposobem na uzyskanie czystego undefined może być np.:

(function(undefined) {
foo == undefined;
})();

Lub:

var undefined = (function () {})();

Lub:

var undefined = void 0;

for in

Nie używamy pętli for in dla tablic!

var a = [1, 2, 3];
for (var i in a) {} // ŹLE!

Komentarze

1

„Nie używamy pętli for in dla tablic!”

święta prawda! :)

Łukasz
2

Niestety
el.addEventListener("click", function () {}, false);
wysypie się w IE, dla którego mamy:
el.attachEvent('onclick', function () {});

Poza tym nie wspomniałeś o podstawowym błędzie nie definiowania zmiennych przez var na początku skryptu/pętli.

3

Można się kłócić, że attachEvent jest niestandardowe, aczkolwiek gwoli uczciwości dodałem, dzięki.

4

Tak tylko z czystego wyszukiwania problemów: uzyskiwanie wartości undefined poprzez [][0] też nie jest do końca pewne, bo ktoś może wykonać Array.prototype[0] = 256; ;-)
undefined można uzyskać jeszcze poprzez zapomnianego operatora void (void cokolwiek, np. void 0), ale ogólnie nie ma co kombinować, tylko utworzyć sobie w lokalnym scopie zmienną bez wartości (var undef;)

5

Fakt, poprawiłem ;-)

6

Wiem jedno – długa droga JS mnie czeka. Chyba się nauczę od nowa

7

w punkcie o ‚var’ dodalbym, ze w przypadku ‚for (i=0; …)’ zmienna i rowniez leci do global scope. to chyba jeden z czestszych bledow.

8

Mam pytanie do for in dla tablic. Po pierwsze – to działa. Po drugie, na dużej ilości stron można zobaczyć coś takiego. Na szybko znalazłem przykład na W3Schools.

Dlaczego zatem nie powinno się używać tej konstrukcji dla tablic?

renq
9

@renq: iterując po tablicy zwykle oczekujesz iteracji tylko po kluczach numerycznych (tab[0], tab[1], …). for .. in nie zagwarantuje Ci tego. Dla for .. in mogą znaleźć się dodatkowe pola, np. takie, które rozszerzyłeś poprzez prototyp tablicy, co w niektórych projektach jest dość częstym zjawiskiem, np. if (!Array.prototype.forEach) Array.prototype.forEach = function (){…}. Dla tego przypadku oczywiście wystarczy sprawdzać tab.hasOwnProperty(key). W ten sposób uzyskujesz nie dość, że warunek do sprawdzania, to też puste przebiegi pętli po niestandardowych kluczach.
for .. in na tablicach nie sprawdzi się też, gdy przypiszesz do tablicy jakieś pole, np. tab.foo = ‚bar’.

Ale podsumowując, każdą ze wskazówek wymienionych w tej notce należy porównać z realiami swojego projektu. Jeśli jesteś pewien, że żaden skrypt na Twojej stronie nie rozszerza prototypu tablicy czy nie dopisuje niczego do instancji tablicy, możesz sobie z for .. in korzystać. Gdyby Damian miał zamiar wchodzić w detale, to jego notka mogłaby urosnąć do wielkości podręcznika nt. JS, a wymienione tutaj rzeczy po prostu przyjęły się jako złe praktyki. Dobre i złe praktyki spisane przez bardziej doświadczonych deweloperów są naprawdę dobrą rzeczą dla nowicjuszy w danym języku, ponieważ pozwalają unikać podstawowych błędów na początku. Wraz z doświadczeniem, użytkownik może zacząć definiować sobie prywatny styl kodowania oraz dobre i złe praktyki.

10

lol.. to napisałeś

1. var Image = „hej Sokoły!”;
2. var img = new Image(); // boom!

„boom” to odgłos facepalm-a jak to zobaczyłem.
odpowiedz mi proszę: jeżeli jakiś idiota siada do kodu i robi coś takiego, to jaki ma sens w ogóle dyskusja o tym? Wydaje mi się że ten poradnik piszesz dla totalnie niszowego bractwa programistów którzy nie wiedzą ze undefined to obiekt że o predefiniowaniu Image nie wspomnę.

Pamiętajmy, że można łatwo nadpisać undefined.

..aż żal mi się robi że mam ferrante w RSS-ach. To tak jak gdyby pisać że window albo document też możesz sobie nadpisać – no po prostu EPIC FAIL. Jeśli można nadpisać, to nie jest to BŁĄD tylko OPCJA.
Mam nadzieję że GETTERY i SETTERY które na razie możesz podziwiać chociażby w silniku Firefoxa, w niedalekiej przyszłości ułatwią Ci życie i nie będziesz musiał pisać tej klasy tekstów

Dając człowiekowi młotek przewidujesz że zacznie nim mordować. lol

operator new tworzy obiekt – no to jak, odbiegamy wg Ciebie od obiektowości? hmmm

dalej.. jeśli już o definicjach i wydajności: definicje zmiennychpowinno się grupować:

var a = {},
b = [];

..a deklaracją „czystego” undefinedmnie po prostu rozjechałeś. Powinieneś dostać nagrodę nobla.
Odpisuj może młodszym kolegom żeby w ogóle unikali JavaScriptu. :P

i nie kasuj mojego posta znowu – bo to cholerny wstyd kolego oceniający kod!
pozdrawiam, kolega po fachu

abrakadabra
11

Ech, dać człowiekowi za darmo garść może prostych, ale wartościowych porad i będzie narzekał. Nie wiem jak Ty, abrakadabra, ale ja jestem programistą, który pisze w językach, które posiadają minimum zabezpieczeń przeciwko strzeleniu sobie w stopę. W JavaScripcie wszystko jest możliwe, więc wspominanie takich rzeczy, nawet do bólu, jest naprawdę czymś, co potem zapada w pamięć, i jak „raz na jakiś czas” muszę w końcu coś zrobić w tym JS, to już nie popełniam błędów, które potencjalnie mógłbym. Przyznam, że akurat TAKICH błędów pewnie bym nie zrobił, bo jednak nawet w takich językach obowiązuje zwyczajne „myślenie”, ale artykuł uznaję za bardzo przydatny.

12

zacny kolego programisto – żaden język programowania nie jest idioto-odporny, tak jak wspomniałem: szeroki wachlarz OPCJI i kombinacji oferowanych przez niektóre z nich działa trochę tak jak młotek – jak chcesz, to możesz nim kogoś nieźle pokaleczyć.
Trochę zmiękło mi serduszko kiedy zacząłeś marudzić na swoje języki programowania.. C++, PHP (jak można marudzić na PHP? hahaha).

Otóż nie wszystko jest możliwe w JavaScript (chociażby nawet ze względu na bezpieczeństwo).. dla przykładu: cross domain – bez kombinacji.
Podsumowując: ja wolę już bardziej coś kupić z dobrego źródła – niestety nie w ojczystym języku (niestety – bo u nas poziom jak widać poraża mi miażdży) niż czytać krajowych samozwańczych „mastahów”.

Btw. coś mi się wydaje że programujesz za dużo w jakimś ezoterycznym języku programowania – same przecinki, nawet przed „i”. :P

abrakadabra
13

@abrakadabra:
To, że nikt (raczej) świadomie nie nadpisze sobie Image, czy undefined, a potem będzie chciał z tego korzystać to chyba oczywiste. Ale pamiętaj, że może to zrobić nie Twój skrypt, a np. jakaś dołączona do projektu biblioteka lub wstrzyknięty kod i nie będąc tego świadomy Twój kod leży lub robi coś innego niż zamierzałeś…

mzl
14

@mzl: Ty chyba jesteś jednym z tych ludzi, którzy wierzą w prawdę książki „proroctwo oriona” o końcu świata w 2012 roku.

„Wtedy przyjdzie haxior to zepsuje twoje wypociny” – nie chcę robić za Goriona, ale raczej robi się tak żeby ten haxior nie przylazł i nie wstrzyknął badziewia przez jakąś dziurę.. a jak już coś dołączasz do projektu, to chyba warto to jednak przeglądnąć chociażby nawet wstępnie.. że o testach nie wspomnę.

abrakadabra
15

@abrakadabra – weź jednak pod uwagę, że kod którego jest więcej niż 10 linii z definicji jest narażony na występowanie w nim błędów. Gdyby tak nie było to nie byłoby kolejnych SP do Windows ;)
@ferrante – dzięki za rzeczowy i przydatny artykuł. Niestety prawda jest taka, że wiele podanych przez Ciebie błędów jest z uporem maniaka wykorzystywana w sieci. To mniej więcej tak jak z tym:
for(int couter=0;counter<10;counter++){

}

Mało osób wie o tym, że lepiej pisać ++counter.

Przykład z C++ podany nieco na siłę, ale ilustruje o co chodzi. Kolejna sprawa to np. tablice, których wcale nie powinno się używać: http://www2.research.att.com/~bs/bs_faq2.html#arrays

16

Drogi Sławku vel abrakadabro,

Rozumiem, że dla tak światłego programisty JavaScript, zawarte tutaj treści stoją na bardzo niskim bądź też – nie bójmy się użyć tego słowa – żenującym poziomie. Jest mi z tego powodu bardzo przykro, że musiał się Pan pofatygować osobiście by to wszystkim uświadomić, tym bardziej, że jak czytamy o Panu w Internecie jest Pan na pewno specjalistą w wielu dziedzinach wiedzy, w tym też tej tajemnej. Liczę też, że przebywa Pan na urlopie bądź nie stawił się jeszcze do pracy i poświęca Pan godziny swojego odpoczynku na komentowanie mojego bloga, bo w innym wypadku byłbym wręcz zaskoczony, że komentowanie moich postów wchodzi w Pana obowiązki. Zaraz, czyżby jednak tak było?

host: pewna znana agencja interaktywna.pl

Bardzo dziękuję Panu za okazałe wsparcie, bo, jak widzę w archiwum, to niejedyny Pana post na moim blogu. Czyżby świadczyło to o długoterminowej, przemyślanej strategii? Nie wiem, gdybam.

W całej Pana świetności, pozwolę sobie jednak o komentarz, choć małym jak ziarenko i nawet cień Pańskiej światłości nie chce na mnie spojrzeć.

Na początku brawa za bardzo trafne spostrzeżenie:

undefined to obiekt

tym bardziej, że

typeof undefined === „undefined”

Dalej jakże celne przypuszczenia:

To tak jak gdyby pisać że window albo document też możesz sobie nadpisać

Co tylko potwierdza poniższa linijka:

var window = 1;
window === 1; // false

Jeśli już o definicjach i wydajności: definicje zmiennychpowinno się grupować:

var a = {},
b = [];

Dokładnie tak, zastrzyk wydajności liczony w sekundach! Także duże bezpieczeństwo, co udowodnił Dean Edwards:

var foo = function () {
var i;
for (i=0; i<10; i++) {
}
for (i=0; i<10; i++) {
}
}

I podczas refactoringu:

var bar = function () {
for (i=0; i<10; i++) {
}
}
var foo = function () {
var i;
bar();
bar();
}

Nie zdarza się to często, ale warto uważać.

Z resztą Pańskich argumentów wręcz nie mam odwagi dyskutować. Liczę, że nie pogrąży się Pan w żalu:

..aż żal mi się robi że mam ferrante w RSS-ach.

doszczętnie i znajdzie na czas w swoim readerze przycisk unsubscribe. Smutny programista to niewydajjny programista, a jeszcze gdyby miał pisać komentarze na blogach...

Tym bardziej, że swój żal okazał Pan już kilka miesięcy wcześniej:

Tak się zastanawiam, gdyby zebrać te wszystkie strony tego Twojego wielkiego zbioru to przestałby mnie trafiać szlag bo klikam i klikam i klikam a tu same podstawy.. troszkę operatorków i nic więcej. :| Fajnych rzeczy jest tam 10%.. reszta to przepisana dokumentacja z MDC.. w dotdatku na slajdach. ROTFL! "mega book of Js art" ;)

Widzę że to jakaś mania.. Ty, riddle i niezliczona ilość kolesi którzy promują się na polskich madafakerów frontendu..

Ewidentnie niezdrowa jest dla Pana lektura polskich blogów o front-endzie. Liczę, że nie dorobił się Pan jeszcze nerwicy czy zgagi.

Jeśli chodzi zaś o język JavaScript, służę dla Pana szkoleniem. Za tak długi staż w komentowaniu tego bloga oferuję nawet 50% zniżki.

Pozdrawiam

17

Co do sensu Twojej argumentacji abrakadabro…

Do pewnego stopnia zgadzam się z argumentem, że nie ma potrzeby się na ogół przejmować tym czy nam ktoś nie nadpisał różnych globalnych zmiennych (jak konstruktory typu Array, czy zmienne jak undefined). Można by więc argumentować, że ta porada nie powinna się znaleźć w tym artykule (dla początkujących). Z drugiej strony można też argumentować, że powinna się znaleźć, ponieważ może się zdarzyć, że ktoś nam niechcący takiego globala kiedyś nadpisze i wtedy może łatwiej będzie się zorientować gdzie szukać błędu.

Można więc argumentować w każdą stronę, ale żeby od razu szydzić?

Z drugiej strony skoro już narzuciłeś ton tej dyskusji, to czemu miałbym nie skorzystać :)

1. „Mam nadzieję że GETTERY i SETTERY […] w niedalekiej przyszłości ułatwią Ci życie i nie będziesz musiał pisać tej klasy tekstów”

Co ma natywne wsparcie dla getterów i setterów do nadpisywania globalnych zmiennych?
Odpowiedź: Nic. Kompromitująca pomyłka #1.

2. „operator new tworzy obiekt – no to jak, odbiegamy wg Ciebie od obiektowości? hmmm”

Ferrante nie narzeka na to, że tworzy się nowy obiekt, tylko, ze wywoływany jest konstruktor obiektu, co jest jakoś (pomijalnie zapewne) wolniejsze, wymaga więcej pisania, oraz jest mniej bezpieczne (już wiemy, że uważasz, że to nie jest problem).

Tyle, że obydwie opcje tworzą obiekt, co więc zatym idzie od niczego nie odbiegamy, czyli Twoja wypowiedź jest bełkotem… Bam! Kompromitacja #2.

3. „definicje zmiennychpowinno się grupować […] var a = {}, b = [];”

Po pierwsze to kwestia konwencji/preferencji, a po drugie ‚var’ deklaruje zmienne, a nie je definiuje (tego drugiego nie da się w JS zrobić). Bam! Nie znamy podstaw JS! Kompromitacja #3.

4. „totalnie niszowego bractwa programistów którzy nie wiedzą ze undefined to obiekt”

Totalnie niszowego bractwa znających podstawy JavaScript?

Otóż undeinfed nie jest obiektem – jest zmienną globalną, której początkową wartością jest wartość prymitywna „undefined” (ale można to zmienić i napdpisać ją czymkolwiek) – wartości prymitywne to nie obiekty.

Efektowna kompromitacja #4, ha!

5. „że o predefiniowaniu Image nie wspomnę”

Predefiniować takie rzeczy to sobie może Twórca silnika JS, a nie my.

Ah, już mi lepiej :) Cztery cudne kompromitacje, w tym pokaz elementarnego braku wiedzy – gratuluję objęcia pozycji lidera.

18

Flame war.. ;)

abrakadabra
19

Nie ma co spierać się z trolem biegłym w erystycznej dialektyce.

20

Dzięki za rady, kilku rzeczy nie znałem. Szczególnie tych nowinek o nowych metodach.

21

drogi kolego po fachu abrakadabro,
1. nadpisywanie Image – skad zalozenie, ze to Ty mialbys nadpisac sobie Image? bledem, ktory opisuje ferrante, nie jest nadpisanie Image. _jest nim zalozenie, ze Image nie zostalo nadpisane._ powiedzmy, ze piszesz bookmarklet, ktory odpalony w nieznanych Ci warunkach. jasne, w wiekszosci wypadkow Image nie bedzie nadpisane, niemniej *jest to mozliwe* i nalezy o tym pamietac. naprawde chcesz pisac kod polegajac na tym, ze inni napisali swoj w taki sposob, ze Twojemu nic nie grozi?

2. undefined to obiekt? oj… ‚4.3.9 Undefined Value: The undefined value is a primitive value used when a variable has not been assigned a value. 4.3.10 Undefined Type: The type Undefined has exactly one value, called undefined.’

3. co do czepiania sie, ze ‚undefined mozna nadpisac’ – nie, window ani document nadpisac nie mozemy (zreszta zalezy to od srodowiska – kto mowi, ze jestesmy w przegladarce?). nie mozemy rowniez nadpisac wiekszosci typow prymitywnych, a brak konsekwencji polegajacy na mozliwosci nadpisania undefined i NaN jest uznawana za blad w zalozeniach jezyka.

4. ‚new’ – oj, to bez ‚new’ obiektow nie stworzymy? Mr Crockford bylby zszokowany.

5. otoz masz racje mowiac, ze zaden jezyk nie jest idioto-odporny. niemniej w przypadku JS, ktory kuloodporny jest mniej niz wiekszosc jezykow, a szansa, ze na Twoj kod moze wplynac kod pochodzacy z innych zrodel, jest wyjatkowo duza – dobre praktyki sa wyjatkowo wazne.

drogi kolego po fachu abrakadabro, Twoj post jest w kilku miejscach bledny, co czyni go szkodliwym. proba dyskredytowania kogos przy uzyciu blednych argumentow opartych na niepelnej wiedzy jest po prostu zalosna. post sprawia wrazenie napisanego przez osobe, ktora troche o JS wie i wydaje jej sie, ze to bardzo duzo. wkurza ja, ze ze swoim – przyznajmy – umiarkowanym poziomem wiedzy nie jest jeszcze slawna w tym naszym wesolym polswiatku, w zwiazku z czym postanowila przyczepiac sie do tych, ktorzy mniej lub bardziej znani juz sa. natomiast Twoj poziom frustracji jest zastanawiajacy. ktos tu kogos nie przyjal do pracy, czy co?

22

@abrakadabra: Faktycznie, żaden język nie jest w stanie zabronić programiście strzelić sobie w stopę, aczkolwiek wspomniane przez Ciebie PHP i C++ jednak pod tym względem są nieco lepsze od JavaScriptu (nie możesz sobie np. bez konkretnego wysiłku nadpisać klasy albo funkcji). I nie rozumiem Twojej ironii w kierunku moim i PHP – na wszystko można marudzić, a PHP bynajmniej idealny nie jest, co nie zmienia faktu, że i tak mi się podoba (BTW. Gdzie znalazłeś moje marudzenie na ww. tematy?). Mówiąc o tym, że „wszystko jest możliwe” miałem na myśli jedynie wykonywanie samego skryptu. Co ma do tego mechanizm cross-domain? Jest to tylko jedna z docelowych możliwości wykorzystania języka, a nie on sam. Co do przecinków – pewnie coś edytowałem w tekście i zostało, nie wiem – staram się pisać z w miarę poprawną ortografią i interpunkcją, ale jak widać nie zawsze wychodzi.

Podsumowując – kup sobie coś z „dobrego źródła”, przeczytaj i podziel się z nami wiedzą. My, nisko kłaniający się Panu klepacze kodu chętnie wchłoniemy w nasze ograniczone polskojęzycznym bełkotem umysły światłe wynurzenia, jakimi nas Pan uraczy.

23

Lubię czytać twojego bloga bo potrafisz w jasny sposób przekazywać ciekawą wiedzę. Z mojego punktu widzenia, wiadomości zawarte w tym poście były bardzo pomocne w zrozumieniu js. Jednak już chwilę po przeczytaniu ostatniej linijki humor popsuła mi zionąca zazdrością i skrzywdzonym ego wypowiedź abrakadabra. Chętnie poczytałbym jego bloga lub cokolwiek innego co daje mu takie poczucie wyższości. Niestety pozostaje anonimowy. Mam nadzieję, że moja firma przypadkiem nie nawiąże współpracy z nieszczęśliwą instytucją zatrudniającą takiego człowieka. Postuluję o zbanowanie abrakadabra, dla dobra pozostałych czytelników.

Maciej Wasilewski
24

Dlaczego zbanować? Jest wolność wypowiedzi, więc moim zdaniem każdy powinien mieć taką możliwość, dopóki nie łamie oczywiście pewnych norm (spamowanie, obrażanie, itp.). Tacy komentujący powinni mieć po prostu świadomość, że w momencie obalenia promowanych przez nich tez narażają się na śmieszność i marginalizację w swojej grupie społecznej. Dlatego m. in. abrakadabra nie ujawnia się, bo automatycznie zostałby przefiltrowany przez środowisko i ludzi, którzy się w nim znajdują.

25

Dokładnie tak, zastrzyk wydajności liczony w sekundach! Także duże bezpieczeństwo, co udowodnił Dean Edwards:

Możesz zapodać linka?

26

Co do definiowania funkcji poprzez function bleble () {};, nie ma większego zabezpieczenia bo wystarczy, że odseparujemy kod od głównego bloku, umieszczając cały w funkjii pozbywamy się efektu nadpisywania zmiennych globalnych (window.blelbe).
co do undefined, myślę, że można prościej:
var undefined;
Również nie do końca popieram taką filozofię „brońmy się przed idiotami”, równie dobrze można zakładać, że jakiś magik, po prostu nadpisze jakąś część naszego kodu, bądź też całą definicję i szczerze interesuje nas czy ktoś grzebał w Object.prototype? Owszem taka zmiana wiele namiesza w naszym kodzie ale już nie z naszej winy.
Bardziej jestem za zwalczaniem bezmyślnych strzałów w stopę, wyrabiając dobre nawyki aniżeli fobii przed idiotami.

billy0o
27

co do undefined, myślę, że można prościej:

Ehe, przeanalizuj ;-):

var undefined = 1;
// [...]
var undefined;
console.log(undefined);

28

zaraz zaraz – przez tą całą kłótnie to przez chwilę i mi namieszaliście I TAK SIĘ POSPINALIŚCIE, ŻE NAWET NIE PRÓBUJECIE ZROZUMIEĆ CO DRUGA OSOBA MIAŁA NA MYŚLI…

i może po kolei – jeśli definiuje się zmienne w globalnym zasięgu – także poza wszystkimi obiektami oraz funkcjami – to nie ma najmniejszego znaczenia czy przed nimi się napisze var czy nie – zmienne i tak lądują do window…

i teraz ostatnie komentarze – co autor miał na myśli…

var undefined = 1;
// [...]
var undefined;
console.log(undefined);

prawda – ale komentarz wyżej też prawda – przykładowy kod:
var undefined = 1;
// [...]
var undefined;
var fTest = function(){var undefined; return undefined;};
console.log(undefined, fTest());

i też nie zrozumiałem, czy poniższe miało działać czy nie – gdyż nie będzie działać tak jak to na pierwszy rzut oka wygląda gdyż zmienna i w funkcji foo nie zostanie ruszona a całość będzie korzystało ze zmiennej window.i
I podczas refactoringu:

var bar = function () {
for (i=0; i<10; i++) {
}
}
var foo = function () {
var i;
bar();
bar();
}

co zresztą można łatwo sprawdzić:
var bar = function () {
for (i=0; i<10; i++) {
}
}
var foo = function () {
var i;
bar();
this.getI = function(){return i;};
}
var t = new foo();
console.log(t.getI(), window.i, i);

co do pewnych zmiennych i konstruktorów to o ile nasz skrypt jest pierwszy na stronie to możemy je zapamiętać (jak np. Image) we własnym zestawie zmiennych przed nadpisaniem i z nich korzystać

pozdro i nie chcę się tu kłócić – takie jak ten artykuł są potrzebne w sieci tylko nie wiem po co robicie żur w komentarzach…

zegarek84
29

Moim zdaniem powinno się jednak wyrzucić takiego psuję, jak abrakadabra.

On po prostu psuje.

To nie ogólny czat, tylko tutorial, wpisy gościa psują całość tak jak przejechanie kluczykiem po samochodzie, żeby napisać właścicielowi że ma niedobry kolor.

Ciekawostką jest, ile energii musiał włożyć w swoje żale i dlaczego to zrobił? Patrzycie po raz wtóry na białogłowę o skazitelnej urodzie? Nie, odwracacie się i idziecie swoją drogą. Abrakadabra najwyraźniej ceni sobie brzydotę (w jego rozumieniu brzydoty) i lubi się patrzeć, a potem wkurzać, a potem patrzeć, a potem znowu wkurzać.

Logos
30

Odnośnie błędów mam takie prawdopodobnie banalne zapytanie.
Mam mały skrypt do ładowanie podstron do div

function Load(div, link) {
$(div).load(link);
}

i wykorzystuje go głównie w takim połączeniu

I mam pytanie co należy zrobić aby do diva #body ładowała się automatycznie strona główna.

Z góry dziękuje za pomoc.

Stavros
31

var Array = 1;
var a = new Array(); // boom!
var b = [] // także boom!

Dodaj komentarz

Dozwolone tagi: <blockquote>, <code>, <strong>