Pięć lub mniej porad dotyczących pisania dobrego JavaScript? [Zamknięte]

14

JavaScript stał się oczywiście niezbędny; jednak wciąż jestem w tym nowy i stwierdziłem, że trudno mi walczyć z uczuciem, że wydaje się, że to taki bałagan, i nie chcę się z tym teraz uporać. Rozumiem języki inne niż JavaScript, ponieważ nie potrafię poradzić sobie z tym strachem. Mam wrażenie, że pisząc JavaScript, staram się namalować portret szczeniąt Weimaraner.

Zwykle pomaga mi pamiętać o kilku najważniejszych dyrektywach, które mogę zadać sobie każdy ruch, który wykonam. (Moim zdaniem garść to pięć lub mniej.)

Czy możesz podać pięć (lub mniej) pytań specyficznych dla JavaScript, które powinienem zadawać sobie przy każdym ruchu, który wykonuję, kiedy koduję JavaScript? Co by to było?

Aktualizacja: aby wyjaśnić, nie proszę o pięć rzeczy, o których należy pamiętać podczas nauki JavaScript; Proszę o pięć pytań, aby zawsze zadawać sobie pytanie, które każdy powinien zawsze zadawać. Pytania na wysokim poziomie, takie jak: „Czy mogę to powtórzyć w innym miejscu?” lub „czy ta nazwa zmiennej / funkcji jest wystarczająco specyficzna (lub zbyt szczegółowa)” <==, z wyjątkiem tych przykładowych pytań, które nie są specyficzne dla JavaScript. Szukam dyrektyw charakterystycznych dla JavaScript.


źródło
3
Pytanie w formie wyrażonej zachęca do wielu odpowiedzi, z których każda byłaby równie ważna. Tego rodzaju pytania nie stanowią dobrych pytań. Czy potrafisz to wszystko sformułować? W przeciwnym razie ma duże szanse na zamknięcie.
ChrisF
2
„Top 5 list” nie jest tym, co robimy tutaj na Programmers.SE. Jeśli chcesz uzyskać odpowiedź na konkretny problem, możesz o to zapytać. W przeciwnym razie sugerowałbym r / Programowanie Reddita do generowania takich list.

Odpowiedzi:

6

Odpowiem na to w dwóch częściach. Jednym z nich jest „Pięć lub mniej porad dotyczących nauki pisania dobrego JavaScript”. Drugi to „Pięć lub mniej porad dotyczących pisania dobrego JavaScript”.

Uczenie się:

  1. Zadawać pytania
  2. słuchać
  3. Czytać
  4. Zrób rzeczy

Robić:

  1. Unikaj globalizacji (modularyzacja)
  2. Wykonuj trudne czynności poza pętlami (wybór DOM, deklaracje funkcji itp.)
  3. Dowiedz się, jak działa zakres
  4. Dowiedz się, kiedy i jak używać zamknięć
  5. Dowiedz się, jak działa Object Oriented JS

EDYCJA (dodawanie pytań w celu zachowania zgodności z PO):

Do jakiego zakresu się odwołuję?

Powinno to pomóc w przypadku przeciekających globałów, procedur obsługi zdarzeń i kiedy używać zamknięć.

Czy się powtarzam?

Ważne jest prawidłowe pozyskiwanie i stosowanie technik OO. Używaj ich mądrze.

Czy mój kod się powtarza?

Niezwykle łatwo jest znaleźć dostęp do DOM w pętli lub tworzyć funkcje (anonimowe lub w inny sposób) w pętli. Należy pamiętać, że może to być prawdą kodu, który używa setTimeoutlub setInterval, jak również tradycyjne pętle.

Czy to oznacza, co myślę, że to oznacza?

Wartości prawdy i fałszu w JS mogą być nieco trudne, szczególnie gdy używa się nieścisłych porównań ( ==w przeciwieństwie do ===). Istotne może być także dynamiczne pisanie, wymuszanie typów i to, czy odwołujesz się do obiektów czy literałów.

Ryan Kinal
źródło
28

Po pierwsze, dowiedz się, jak działa ta technologia.

Musisz to wiedzieć, ponieważ wiedza na temat tego, jak to działa, ponieważ napotkasz problemy z siecią lub, jak widziałem niezliczoną ilość razy, ludzie całkowicie nieświadomie rozumieją, czym tak naprawdę jest strona serwera i strona klienta. Jednym z najczęstszych pytań newb, które widzę, jest: „Jak zmusić JS do zmiany zmiennej w kodzie ASP ?!”

  • Czy rozumiesz Ethernet / WiFi i TCP / IP, aby mieć ogólne pojęcie o tym, co się dzieje?
  • Ile faktycznie znasz HTTP?
  • Czy faktycznie dostajesz HTML? Jasne, możesz wiedzieć, jak działają tagi i zagnieżdżać różne rzeczy, ale czy naprawdę rozumiesz tryb doctype i dziwactwa? Czy rozumiesz, że nie powinieneś umieszczać tagów akapitu wokół elementu listy?
  • Wymyśl JavaScript (i wyjaśnij, że można go uruchomić po stronie serwera). ecmascript, livescript, mocascript, jsscript, węzeł ...
  • Naucz się Windows API, naucz DOM API i naucz API XHR. Jeśli nie znasz tych trzech rzeczy, nie masz biznesowego kodu do przeglądarki.

Zrozum, że Twój kod jest większy niż Ty lub Twoja konkretna sytuacja

  • Jasne, coś napisałeś, ale każdy to widzi. To wszystko jest „otwarte” źródło. Jasne, możesz go zaciemnić, zminimalizować, cokolwiek ... na koniec dnia, jeśli chcę zobaczyć twój kod, to dla mnie trywialne jest pokonanie wszelkich metod, które zastosujesz.
  • Musisz zrozumieć wiele różnic między przeglądarkami. Kieruj reklamy na najpopularniejsze lub te, które ma Twoja grupa demograficzna. Na przykład ie6 nie będzie renderować elementów tabeli komórkowej DOM, jeśli dodasz AppChild zamiast metod DOM API specjalnie dla tabel. Istnieje więcej przykładów, musisz się ich nauczyć.
  • Musisz zrozumieć, jak pisać kod do wszystkich tych problemów w przeglądarkach, a nie w konkretnej przeglądarce. Szybko nauczysz się, że rzeczy, które działają dobrze w jednej przeglądarce, są wolne w innej. Musisz dowiedzieć się, jak działają przeglądarki i dlaczego się różnią.
  • Z miłości do brody Odyna nie pisz kodu, który pozwala mi przeprowadzać ataki typu cross-site-scripting na Twój kod. Jeśli wykonasz wywołanie ajax do komórki i zrobisz coś podobnego cell.innerHTML = "<script>alert("xss")</script>", a pojawi się okno alertu, zrobiłeś to źle.
  • Trzymaj się z daleka od DynamicDrive, w3Schools i stron internetowych, które dają złe porady. Musisz znaleźć społeczności, które dadzą dobrą radę. Tutaj na przepełnieniu stosu mamy czaty JavaScript i Node.JS, i dokładamy wszelkich starań, aby przekraczać granice tego, co jest „lepsze”, gdy witryny takie jak w3s przechowują nieaktualne dane i nigdy się tym nie przejmują. Powinieneś trzymać się oficjalnych stron takich jak W3C , Mozilla Developer Network (MDN). Poproś o weryfikację Twojego kodu. Kiedy czujesz, że robisz coś bolesnego ze swoim kodem, kiedy robisz dużo wycinania, wklejania i poprawiania swojego kodu, powinieneś natychmiast przyjść do pokoju rozmów i poprosić o wskazówki na temat pisania lepszego kodu.
  • Gdy przychodzisz po wskazówki lub chcesz podzielić się tą naprawdę fajną rzeczą, którą stworzyłeś ... proszę, proszę bardzo. Upewnij się, że to udokumentowałeś, upewnij się, że twoje nazwy zmiennych mają sens, upewnij się, że nie wszystkie są jednowierszowe. Musisz napisać czysty kod. Jeśli masz stos śmieci, nie tylko zawiodłeś, ale nikt, kto wie, jak ci pomóc, nie będzie chciał . Pomóż nam pomóc.
  • Chcesz pisać JavaScript - to fajnie, szanuj, że nie wszyscy obsługują JavaScript. Dwa powody tego: 1) Szybszy Internet dla wszystkich (zamiast „ajax wszystkich rzeczy”, co prowadzi do wolniejszego korzystania). 2) Sieć jest bardziej dostępna dla osób korzystających z przeglądarek konsolowych, osób bez skryptów i telefonów komórkowych. Próbuję powiedzieć, że twoja strona powinna się z wdziękiem degradować, jeśli ktoś nie ma JavaScript, a przynajmniej użyj <noscript>tagów, aby ostrzec go o tym.
  • Ze względu na prototypowy charakter JavaScriptu możesz wprowadzać zmiany w sposobie działania języka - co jest naprawdę słodkie. Widzisz, JavaScript ewoluuje, wyciągamy „ECMA Script 3”, czyli starszą wersję JS, i „ECMA Script 5” (aka, es5). Dzięki prototypowi możemy naprawić język es3 w terenie, aby działał jak es5. Oznacza to, że tj. 6, 10-letnia przeglądarka ma funkcję języka, która pojawiła się w zeszłym roku. Używaj podkładek ES5, gdziekolwiek możesz, są naprawdę fajne i musisz to sprawdzić.
  • Zachodni świat anglojęzycznych białych dzieci nie jest tym, kto korzysta z Internetu. Kod odpowiednio. Oznacza to, że musisz zrozumieć internacjonalizację i pisać kod, który odpowiada na większe zapotrzebowanie. 10 lat temu w Internecie było mniej niż 500 milionów ludzi, dziś jest to około 2 miliardy, a za kolejne 10 lat? Prawdopodobnie blisko każdej osoby na świecie będzie miał dostęp do Internetu, co oznacza, że ​​musisz obsługiwać nazwy, które nie pasują do wyrażenia regularnego /[a-z ']/i, ale zawierają akcenty w języku hindi, arabskim (jest to problem istniejący od niedowidzących programistów), chiński , i inni. Zrozumienie zestawów znaków, Unicode i UTF-8.

Jesteś programistą, a nie fabryką makaronów. Przestań pisać spaghetti.

  • Nazwij zmienne według rzeczy, które mają sens.
  • Udokumentuj swój kod. Nie obchodzi mnie, czy używasz JSDoc zasilanego przez nosorożca, czy masz sporo bazgrołów. Napisz dokumentację, która pomoże osobie, która zamierza użyć twojego kodu. Napisz dokumentację dla kogoś, kto chce ulepszyć lub utrzymać kod. Dołącz przydatne komentarze. Komentarze takie jak "This fizzes the bizz"lub te w połowie angielskie, w połowie francuskie, nie są pomocne. Opisz, co robi funkcja. Opisz złożone sekcje kodu.
  • Dowiedz się, jak ograniczyć powtarzanie kodu. Poszukaj modułowej konstrukcji lub funkcjonalnych wzorów. Zobacz, co możesz streścić. Nigdy nie powinieneś przecinać + wklejać + poprawiać dużych segmentów kodu, aby zrobić to samo.
  • Musisz zrozumieć DOM API. Udostępnianie obiektów DOM i obiektów okiennych dla wielu wspaniałych rzeczy. To brzmi jak dużo pracy, ale to dlatego, że to duży przerażający akronim. Wielu z was ninja JavaScript lubi pisać kody takie jak <a href="javascript:alert("foo")">. FFS NIE RÓB TO. Poczekaj na załadowanie pełnego dokumentu, oddziel kod JavaScript od dokumentu HTML. To są podstawowe praktyki OOP 101, po prostu nigdy nie umieszczaj JS lub CSS w dokumencie HTML. Zastanów się, jak to zrobić poprawnie lub znajdź kogoś, kto wie, jak to zrobić. Ponownie zadawaj pytania.
  • Javascript:foo("buz")jest psudeo-protokół, to nie jest w pełni obsługiwany, a jeśli nie w linii javascript nie będzie go używał w pierwszej kolejności. Obiecuję wam z głębi serca, że ​​nie ma żadnego powodu na tej ziemi ani nigdzie we wszechświecie, że POTRZEBUJESZ umieścić javascript w elemencie HTML. Zawsze. Więc nie rób tego. Nawet nie pomogę ludziom, którzy to robią, to takie złe.

Zastanów się, jak napisać kod w taki sposób, aby nie łamał się cały czas.

  • Zmienne globalne są jednym z największych problemów. Dowiedz się, jak działa funkcjonalne programowanie w JavaScript. Dowiedz się, co to jest podnoszenie. Dowiedz się, jak unikać zmiennych globalnych.
  • Użyj narzędzi do analizy kodu statycznego. Powodują one natychmiastowe powiadomienie o wszystkich małych „ups”, które poczyniłeś podczas pisania kodu. Zapomniałeś gdzieś średnika? Och, oto jest. Masz gdzieś globalny? Och, oto jest. Kod, który może generować wiele tajemniczych błędów, gdy próbujesz go uruchomić? O! Oto oni! Nie musisz już grzebać i wpatrywać się w stos kodu przez wiele godzin, próbując znaleźć coś, co jest tylko błędem składni. (Cóż, prawie żaden, mógłbyś zrobić coś, czego nie można złapać, ale ogólnie jest niesamowity).
  • Test jednostkowy Nie ma powodu, aby nie być. Tam jest mnóstwo narzędzi do testowania jednostek. Zasadniczo, testowanie jednostkowe to „Oto moja funkcja” i „Chcę, aby wyświetlała Y” „Oto kilka danych wejściowych testowych” A test brzmi „Czy wszystkie działały?” Istnieje wiele frameworków testujących JS, takich jak popularny QUnit. Wybierz się na wycieczkę po swojej ulubionej wyszukiwarce i zobacz, co Cię podoba. Ale skorzystaj z nich.
  • Zarządzanie kontrolą źródła, znane również jako kontrola wersji. Git jest popularny i nie bez powodu. Podobnie jest z SVN i kilkoma innymi. Tym, czego potrzebujesz, aby przestać robić to natychmiast, jest edycja kodu produkcyjnego. Musisz przestać zmieniać nazwy plików main_backup_20110911.js.bak.1Tracisz pliki, katalog staje się nieuporządkowany, nie możesz łatwo „przewinąć” do poprzedniego punktu w czasie. Nie widzisz, co się dzieje, nie możesz tworzyć poprawek do kodu. Zacznij więc naukę GIT, zajmie ci to godzinę, a już nigdy nie wrócisz.
  • Recenzja. Nie jesteś taki dobry, ja też nie. Poprawiam się, prosząc o opinie tak dużo, jak potrafię. Tak też powinieneś to zrobić.

Napisz JavaScript, który ludzie kochają

  • Dowiedz się, dlaczego twój kod jest wolny. Użyj jspref i utwórz testy.
  • Przestań wiązać zdarzenia z jednym elementem DOM, jest on powolny i stwarza poważne problemy z propagowaniem zdarzeń, które zmarnują dużo czasu. Badanie „delegowania zdarzeń” w JavaScript.
  • ZATRZYMAJ korzystanie z innerHTML do edycji DOM. Wróćmy do nauki HTML i DOM. HTML to dane wysyłane z serwera, którego silnik renderujący w przeglądarce używa do tworzenia wiązki obiektów programistycznych, które ostatecznie są obiektami dokumentowymi. Kiedy używasz innerHTML, pytasz swoją przeglądarkę o ponowne renderowanie całości. Na szczęście, podobnie jak ponad 10 lat temu, stworzyliśmy interfejs API DOM, który pozwala „dołączyć dziecko” lub „utworzyć węzeł tekstowy” bez konieczności aktualizacji całości. innHTML to hańba, którą wymyślił Microsoft - jeśli go użyjesz, stracisz również wszelkie przywileje narzekania na temat okropności IE6, ponieważ pomagasz mu na zawsze trzymać się śmieci. Dowiedz się o DOM.
  • Musi działać wszędzie, gdzie może. Jeśli coś nie jest obsługiwane, musi z wdziękiem się zepsuć, aby doświadczenie nie było do kitu - nie możesz po prostu uderzyć użytkowników w twarz i upaść.
  • Prawa autorskie i licencja są ważne. Nie odrywaj ciężkiej pracy innych ludzi. Jeśli ktoś powie „nie do odsprzedaży”, nie możesz go sprzedać. Nie bądź palantem, bo znienawidzimy Twój kod za zdzieranie ciężko pracujących ludzi.
  • JS to prototypy, a nie klasy. Przestań to robić. Jeśli nie rozumiesz, jak działa prototyp, musisz to zrobić. Wygoogluj to. JavaScript nie jest oparty na klasach, przestań tworzyć klasy, bardzo rzadko działa dobrze. Ludzie próbują pisać klasyczny kod w języku prototypowym i używają tego jako argumentu „dlaczego język jest do bani”, tak samo mogę powiedzieć, że Ruby nie jest w stanie wesprzeć prototypu. Naucz się czegoś nowego i przestań robić to źle.

Zawsze koncentruj się na podstawach.

  • Mylisz się, i to jest niesamowite, ponieważ teraz coś wiesz. Nie ma nic gorszego niż ktoś, kto nie przyzna się do błędu i ciągle wyrzuca z siebie zły kod, jakby był jakimś renegatem ninja gwiazdą rocka. Oni są tylko głupcami. Przyznaj się, że możesz się mylić, przyznaj się do błędu, poproś o pomoc.
  • Nie zawsze potrzebujesz jQuery. jQuery tworzy dużo wolnego kodu i pomaga ludziom, którzy nie znają JS, do pisania JS. Jest to kolejny problem, ponieważ JS nie wymaga znajomości JS do pisania JS. Domyśl. Kiedy zrozumiesz kilka rzeczy, o których wspomniałem powyżej, takich jak uczenie się wydarzeń, uczenie się DOM, uczenie się o innerHTML, zobaczysz, dlaczego jQuery może być szkodliwy dla twojego kodu. Może być używany poprawnie w wielu miejscach, ale często możesz użyć mniejszej biblioteki lub nawet wypróbować standardowy JavaScript dostarczony z przeglądarką, aby coś osiągnąć. Nie potrzebujesz jQuery, aby cokolwiek zrobić, ułatwia to napisanie kodu, który jest fajny, jeśli się uczysz, ale musisz zacząć robić lepiej i uczyć się więcej - kiedy wiesz więcej, dowiesz się, jak to zrobić i tak napisz lepszy kod w jQuery.Sprawdź inne biblioteki JavaScript i przestań być tak blisko siebie.
  • Nie potrzebujesz wycinania + wklejania + poprawiania, tworzenia kodu DRY. Wspominałem o tym wcześniej, ale tutaj też jest to ważne. Nie możesz napisać kodu jakości, jeśli twoja baza kodu jest hańbą.
  • Nie nadużywaj tablic / różnic obiektów, naucz się zapętlać. Dowiedz się, dlaczego używasz a for (;;)i dlaczego używasz for( in )pętli. Kiedy używać pętli while. Przestań zagnieżdżać IF, jeśli możesz po prostu użyć skrzynki przełączników. Obiekty nie zachowują porządku, więc nie używaj ich jako tablicy; stara Opera / FF, stara BRAK, czasem Flash nie uszanuje kolejności twoich obiektów. Użyj tablicy, jeśli chcesz zachować porządek rzeczy, użyj obiektu, jeśli chcesz obiekt (coś, co nie ma porządku elementów).
  • Jak wykorzystać struktury decyzyjne na swoją korzyść, a nie zwiększać złożoności kodu. Przestań zagnieżdżać IF, dowiedz się, jak działają logiczne operatory logiczne. Dowiedz się, jak działa skrzynka rozdzielcza.
  • RTFM. Najlepszym miejscem do zapoznania się z lepszym kodem jest przeczytanie aktualnej specyfikacji. Przeczytaj specyfikacje RFC w tej części kodu, której próbujesz użyć. Przeczytaj dokument ECMAScript. Przeczytaj specyfikację DOM W3C. Przeczytaj specyfikację W3C XHTML / HTML / HTML5. Przeczytaj specyfikacje, są dobre.

Skoncentruj się na długiej grze, a nie na szybkim flashowaniu i zgiń.

  • Powinieneś pomóc społeczności, powinieneś napisać kod, który będzie dostępny przez długi czas. Miej pasję do swojego kodu i społeczności. Jeśli gdzieś zostawiłeś złą wiedzę, wróć do diabła i napraw ją. Złe informacje są naprawdę trudne do usunięcia i zostają na zawsze. Zrobić swoją rolę. Nie pomagaj w3schools pogarszać sieć.
  • Nie wskakuj z nikąd i nie mów „Hej, mam świetny pomysł na użycie which” upuść kilka kodów, których nikt nie może użyć i zniknąć. Nic nie wniósłeś. Nie używaj zmiennych takich jak ai chezburger.
  • Naucz się rozpoznawać zły kod i dobry kod, znajdź go we własnym kodzie, przekształć zły kod w dobry kod.
  • Stwórz coś, naucz się czegoś, naucz czegoś.
  • Poszerzać horyzonty. Nie możesz po prostu pisać JavaScript na zawsze - weź urlop naukowy w coś, co Cię interesuje, wróć, podziel się tym, czego się nauczyłeś i sprawdź, czy możesz znaleźć dla niego miejsce w społeczności. Spróbuj pokazać światu, jaką wartość ma JavaScript w czasie, gdy tam jesteś.
  • Nadal się mylisz, nawet jeśli wiesz wszystko. Użyj poprawnego dowodu, a nie swojego statusu / władzy. Nigdy nie możesz mieć racji, ale twój dowód jest zawsze poprawny. Nie wdawaj się w sikające mecze, choć czasem tak trudno jest tego uniknąć. Albo jest dowód, albo nie ma. Płomienie nikomu nie pomagają.

Dla wszystkich zainteresowanych tak naprawdę wzięłem większość z osobistych notatek z samouczka, którego nigdzie nie pisałem.

Incognito
źródło
Twoja odpowiedź u góry całkowicie pomieszała HTTP i HTML.
Bryan Boettcher
@insta Jestem bardzo celowy, mówiąc, że musisz zrozumieć HTTP. Jak powiedziałem: „Jednym z najczęściej zadawanych pytań newb jest:„ Jak zmusić JS do zmiany zmiennej w kodzie ASP ?! ”. Nie rozumieją protokołu, który przenosi zawartość HTTP, pliki cookie i nagłówki z serwer do klienta. Próbuję powiedzieć, że trzeba znać warstwy, aby nie pomylić tych rzeczy. Aby wyrazić to funkcjonalnie, powiedziałbym: TCPIP(HTTP(ClientServerRelationship(), Cookies(), HTML(JavaScript(Knowledge))))
Incognito,
1
„Czy rzeczywiście otrzymujesz HTTP? Pewnie, możesz wiedzieć, jak działają tagi i zagnieżdżać różne rzeczy, ale czy tak naprawdę rozumiesz tryb doctype i dziwactwa? Czy rozumiesz, że nie powinieneś umieszczać tagów akapitu wokół elementu listy?” Nic w tym cytacie nie dotyczy protokołu transportu poza przypadkiem niewłaściwego wykorzystania.
Bryan Boettcher
1
@insta Ach przepraszam, zupełnie tego nie widziałem, zmieniłem go na HTML. Dzięki :).
Incognito,
1
+1 To zdecydowanie lepsza odpowiedź niż zaakceptowana
Tom Squires,
7
  1. Przeczytaj Javascript Douglasa Crockforda : Dobre części . To całkiem wskazówka, ale szczerze mówiąc, to najlepsza rada, jaką kiedykolwiek słyszałem o pisaniu dobrego javascript.

  2. Podobnie przeczytaj artykuły Douglasa Crockforda na temat Javascript .

NT3RP
źródło
9
Ale nie bierz tego religijnie. Spójrz na to i upewnij się, że ma to dla ciebie sens. Zadawaj pytania tam, gdzie nie rozumiesz celu.
Incognito,
3
alert('This illustrates how JavaScript has first-class functions');
alert('It also illustrates how to use closures.  Try running this code in your browser.');

var funky = function(s) {
    alert("We're getting funky with " + s);
};

var makeFunkyObject = function(funkyFunction) {
    var numberOfTimesAlerted = 0;
    var fn = { };
    fn.alertFunky = function(s) {
        funkyFunction(s);
        numberOfTimesAlerted++;
    }
    fn.getNumberOfTimesAlerted = function() {
        return numberOfTimesAlerted;
    }
    return fn;
}

var funkyObject = makeFunkyObject(funky);

funkyObject.alertFunky('Alice'); // alerts We're getting funky with Alice
funkyObject.alertFunky('Bob'); // alerts We're getting funky with Bob
alert(funkyObject.getNumberOfTimesAlerted()); // alerts 2

alert('Also, be sure to distinguish between learning about JavaScript and learning about the DOM');
alert('The former is awesome; the latter, not so awesome.');
Ciastka Z Mąki Ryżowej
źródło
+1: Gdy to zrobisz, staniesz się ninja javascript.
Spoike,
2

Oto kilka pytań, które powinny zachęcić Cię do korzystania z JavaScript.

  1. Jak działa JSON i do czego służy?

  2. Dlaczego funkcje są obiektami w JavaScript?

  3. Dlaczego nie powinienem używać eval?

  4. Jak tworzyć zdarzenia w javascript?

  5. Jak mogę wykryć funkcje w javascript?

Prawie obejmuje większość rzeczy, które musisz zrobić w JavaScript.

Łup
źródło
1
  1. Zawsze używaj średników. Niejawne średniki (w JS) są okropnym pomysłem, szczególnie z niektórymi interesującymi składniami unoszącymi się w powszechnym użyciu. Są one również na ogół wymagane przez dowolny minimalizator JS.
  2. Unikaj eval () . Powoduje to różnego rodzaju problemy i jest bardzo szybkim sposobem na spowolnienie działania aplikacji. Większość zastosowań to nadużycia. Za każdym razem, gdy uważasz, że musisz użyć eval(), sprawdź dwukrotnie i potrójnie w inny sposób; prawie zawsze istnieje czystszy i łatwiejszy sposób, chyba że faktycznie próbujesz wykonać całą wartość JavaScript.
  3. (function() {/* stuff */})()to dobry sposób na zamknięcie zestawu kodu i utworzenie dla niego zasięgu lokalnego. Używanie obiektów to inny, często lepszy sposób; obiekty są bardziej analogiczne do przestrzeni nazw w innych językach, jeśli są używane w ten sposób. Tylko uważaj na this. W przeciwieństwie do większości innych języków, thisnie zawsze odwołuje się do tego, co można intuicyjnie sądzić. Pamiętaj również, że jeśli nie określono inaczej, wszystkie zmienne JS, funkcje i inne obiekty są globalne, nawet w wielu .jsplikach.
  4. Znajdź i ucz się / korzystaj z dobrej biblioteki JS. jQuery jest jednym z bardziej popularnych. Spowoduje to wiele ciężkich obciążeń, w tym wykrywanie funkcji i wyodrębnianie manipulacji DOM oraz różne sposoby implementacji różnych rzeczy w różnych przeglądarkach.
  5. Zawsze używaj średników. Poważnie. Zdobądź IDE, które ostrzeże Cię, gdy je zapomnisz. Nie chcę brzmieć łobuzersko, ale kilka razy wprowadzono błędy tylko z powodu braku średnika, a przeglądarka cię o nich nie ostrzeże.
Matthew Scharley
źródło
Nie zawsze potrzebujesz średników, jednak zgodzę się, że to dobra praktyka.
rlemon
1
Reguły ASI są takie same we wszystkich silnikach JS, więc kod w jednym miejscu powinien zachowywać się tak samo w innym. Miło jest widzieć średniki we wszystkich właściwych miejscach, ale prawdopodobnie nie zabije cię tak, jak inne problemy. To powiedziawszy, powinieneś wystrzegać się ASI, robienia takich rzeczy return, a następny wiersz zawierający twoje dane, tak naprawdę powiedziałeś z return ;powodu ASI. Powiedziałbym, że ważniejsze jest zrozumienie reguł ASI i białych znaków niż „zawsze używaj średników”. Ale to świetny sposób na uratowanie siebie.
Incognito
+1 za unikanie eval, -1 za paranoję średnikiem. Wstawianie średnika JavaScript ma określone reguły, które, jeśli są przestrzegane, są bardzo logiczne. Sprawdź to
Ryan Kinal
@Incognito +1I'd say it's more important to understand ASI and whitespace rules than it is "always use semicolons."
rlemon
Dla każdego, kto mówi, że nie zawsze potrzebujesz średników; wróć do nas, gdy wykonasz rzeczywiste tworzenie przeglądarek w javascript (patrz IE6, 7 i 8).
Spoike,
0

Uważam, że klasy są dość potężnym narzędziem do struktury kodu. Istnieje wiele zasad agnostycznych z języka, dotyczących projektowania systemów opartych na klasach, a niektóre zasady OO są w rzeczywistości bardziej oczywiste zaimplementowane podczas korzystania z klas.
Dlatego proponuję rzucić okiem na CoffeeScript .

Stamtąd sugeruję, abyś po prostu zebrał informacje o tym, jak wdrożyć SOLID , DRY , GRASP , KISS i YAGNI , a co ważniejsze, jak postępować w sytuacjach, w których wydają się być w konflikcie (nigdy tego nie robią, tylko ich zrozumienie lub problem na bieżąco). Jest dość łatwy do znalezienia, nawet przy wymianie stosów.

Pamiętaj, że zasady te dotyczą w równym stopniu „surowego” programowania JavaScript. Jednak wiele treści, które można na nich znaleźć, zilustruje je przy użyciu języków opartych na klasach i dlatego może być przydatne do programowania w języku, w którym nie ma zbyt dużego nakładu pracy na ich zrozumienie.
Osobiście uważam, że JavaScript jest niezwykle potężnym językiem, ale tak naprawdę musisz najpierw dobrze zrozumieć inne języki, aby naprawdę docenić ten fakt.

back2dos
źródło
-7

Zakładam, że używasz JavaScript do tworzenia interfejsu użytkownika po stronie klienta w aplikacji internetowej.

1) Czy powinno to być po stronie klienta, czy po stronie serwera? Wiem, że odszedłem i napisałem poważne fragmenty kodu, które naprawdę zasługiwały na bycie na serwerze i odwrotnie. Wiele razy zastanawiam się nad wywołaniem AJAX, aby coś, co ostatecznie po prostu lepiej znalazło się w kodzie serwera, zostało uwzględnione po drodze. Szczególnie rzeczy o charakterze statycznym, ale zmieniające się dość regularnie (na przykład lista kategorii).

2) Czy istnieje wtyczka, która już to robi? Często używam JQuery, a odpowiedź brzmi prawie zawsze TAK! Często biorę kod wtyczki, który ktoś napisał, i dostosowuję go do moich potrzeb (zwykle dodając dodatkowe klasy do rzeczy itp.), Ale rzadko muszę zaczynać od zera.

3) Czy Javascript jest właściwym miejscem do tego? Czasami przyłapuję się na dodawaniu do zestawu całej gamy dynamicznych stylów, kiedy bardziej sensowne jest używanie inteligentnego CSS.

4) Czy powinienem używać innego narzędzia? Z tym ostatnio zmagam się. Istnieje kilka alternatyw javascript, takich jak skrypt kawy, które są dobrze obsługiwane na moim stosie (Rails 3.1) i zastanawiałem się, czy przenieść tam duży kod.

5) Czy ten kod JavaScript jest dobrym kodem? JavaScript jest kodem jak każdy inny kod. Czy ten kod jest tak dobry, jak reszta mojego kodu? Jeśli nie, dlaczego nie? Czy to jest jednorazowe? Czy jestem leniwy?

Rysował
źródło
4
Twoje wskazówki na temat pisania dobrego JavaScript to: „Nie pisz JavaScript” i „Pisz dobry JavaScript”. Przepraszamy, -1
Ryan Kinal,
1
@RyanKinal Zawiera „Używaj jQuery przez większość czasu”. Samo to jest dużym problemem.
Incognito,
2
@ f0x Dlaczego tak mówisz? Dlaczego nie chcesz korzystać z pracy wykonanej przez kogoś innego?
Drew
2
@Ryan, twoja odpowiedź na „wymień pięć lub mniej pytań, które powinienem sobie zadać” obejmowała trzy dyrektywy, które zaczęły się od „ucz się [takie i takie] ...”), co jest ogólnie dobrą radą, ale szczerze mówiąc, zadałem tutaj coś naprawdę konkretnego: pytania, które powinienem zadawać sobie przy każdym ruchu, który wykonuję podczas kodowania JavaScript. Nie „czego powinienem się nauczyć, aby zrozumieć JavaScript”. Drew jest jedyną osobą, która odpowiedziała na zadane pytanie.
2
@ f0x Nie mówię, że powinieneś ślepo używać wtyczki niezależnie od tego, czy ma to sens, ale wszyscy używamy narzędzi udostępnianych przez innych, w przeciwnym razie wszyscy używalibyśmy własnej wersji asemblera. Wtyczki mogą dać ci doskonały punkt wyjścia, od (a) bezpośredniego rozwiązania problemu lub (b) dając ci wgląd w to, jak inni rozwiązali problem, który próbujesz rozwiązać.
Drew