20 Allemaal te vaak voorkomende valkuilen voor beginners

Ongeacht ons huidige niveau waren we allemaal op een bepaald moment beginners. Het maken van klassieke beginnersfouten komt met het territorium. Vandaag hebben we verschillende Nettuts + personeelschrijvers gevraagd om hun valkuilen en oplossingen te noemen - in verschillende talen.

Leer van onze fouten; doe deze dingen niet!


JavaScript-tips

1 - Onnodige DOM-manipulatie

De DOM is langzaam. Als u uw interactie hiermee beperkt, zullen de prestaties van uw code aanzienlijk toenemen. Beschouw de volgende (slechte) code:

 // anti-pattern for (var i = 0; i < 100; i++) var li = $("
  • ") .html (" Dit is lijstitem # "+ (i + 1)); $ (" # someUL "). toevoegen (li);
  • Deze code eigenlijk modificeert de DOM 100 keer en creëert onnodig 100 jQuery-objecten. 100! Een meer correcte benadering zou zijn om een ​​documentfragment te gebruiken of een reeks samen te stellen die de 100 bevat

  • elementen en voegt die HTML vervolgens toe aan het bevattende element. Op die manier spring je een keer in de DOM. Hier is een voorbeeld:

     var liststring = ""; for (var i = 100; i> 0; i -) liststring + = "
  • Dit is lijstitem # "+ (99-i); document.getElementById (" someUL "). InnerHTML (liststring);
  • Zoals hierboven opgemerkt, raken we met deze techniek de DOM slechts één keer aan, wat een verbetering is, maar hij is ook afhankelijk van tekenreeksaaneenschakeling om een ​​grote tekenreeks te maken. Er is een andere manier om dit te benaderen, met behulp van arrays.

     var liststring = "
  • "var lis = []; for (var i = 100; i> 0; i -) lis.push (" Dit is lijstitem # "+ (99-i)); liststring + = lis.join ( "
  • ") +"
  • "; document.getElementById (" someUL "). innerHTML (liststring);

    Wanneer u grote reeksen bouwt, slaat u elk stuk van de reeks op als een item binnen een array-element en belt u join () is aantoonbaar meer elegant dan string concatenation. Dit is een van de snelste en gemakkelijkste manieren om terugkerende HTML in JavaScript te bouwen zonder een sjabloonbibliotheek of raamwerk te gebruiken.

    2 - Inconsistente variabelen- en functienamen in JavaScript

    Dit volgende item is geen prestatieprobleem, maar is uitermate belangrijk - vooral als u werkt aan code waaraan andere mensen ook werken. Houd uw identificatiegegevens (variabele en functienamen) consistent. Beschouw de volgende variabelen als een voorbeeld:

    var foo = "bar"; var plant = "groen"; var car = "red";

    Het zou niet logisch zijn om nog een variabele toe te voegen, genaamd Iets. Dit introduceert inconsistentie in uw variabel naamgevingspatroon, waardoor uw hersenen deze variabele cognitief markeren als zijnde anders of speciaal. Dit is de reden waarom constanten in de meeste talen traditioneel worden gedefinieerd met alle hoofdletters.

    Je kunt een stap verder gaan door dezelfde lengte, grammaticale structuur en verklarende aard te behouden bij het benoemen van functies. Overweeg bijvoorbeeld de volgende gekunstelde functie:

    functie subtractFive (nummer) retournummer - 5; 

    Het benoemen van een functie die vijf aan een gegeven getal toevoegt, moet hetzelfde patroon volgen, dat hier wordt weergegeven:

    functie addFive (getal) retournummer + 5; 

    Soms noemt u een functie om de retourwaarde aan te geven. U kunt bijvoorbeeld een functie benoemen die een HTML-tekenreeks retourneert getTweetHTML (). U kunt ook de naam van een functie toevoegen met do, als de functie eenvoudig een bewerking uitvoert en geen waarde teruggeeft, bijvoorbeeld: doFetchTweets ().

    Constructorfuncties volgen meestal de traditie van lessen in andere talen, waarbij de eerste letter als hoofdletter wordt gebruikt:

    functie Hond (kleur) this.color = kleur; 

    Als algemene vuistregel geldt dat u beschrijvend moet zijn bij het benoemen van uw identificatiegegevens. Classificeer ze samen met andere soortgelijke identificatiegegevens door een naamgevingspatroon te behouden dat leesbaar is en hints biedt voor de aard van de doelstelling van een variabele of functie.

    3 - Gebruik hasOwnProperty () in voor in Loops

    De arrays van JavaScript zijn niet associatief; proberen om ze als zodanig te gebruiken, wordt door de gemeenschap afgekeurd. Objecten kunnen daarentegen als hash-tabellen worden behandeld en u kunt de eigenschappen van een object doorlopen met behulp van de voor in loop, zoals zo:

    for (var prop in someObject) alert (someObject [prop]); // waarde van eigenschap van waarschuwing

    Het probleem is echter dat de voor in lus itereert over elke opsombare eigenschap op de prototypeketen van het object. Dit kan problematisch zijn als u alleen de eigenschappen wilt gebruiken die op het werkelijke object aanwezig zijn.

    U kunt dit probleem oplossen met behulp van de hasOwnProperty () methode. Hier is een voorbeeld:

     for (var prop in someObject) if (someObject.hasOwnProperty (prop)) alert (someObject [prop]); // waarde van eigenschap van waarschuwing

    Deze versie waarschuwt alleen de waarden van de eigenschappen waarop zich direct bevindt someObject.

    4 - Boolean-waarden vergelijken

    Booleaanse waarden in een conditie vergelijken is een verspilling van rekentijd. Bekijk het volgende voor een voorbeeld:

    if (foo == true) // doe iets voor true else // doe iets voor false

    Let op de voorwaarde: foo == true. De vergelijking van foo en waar is onnodig omdat foo is al een booleaanse waarde (of het is een waarheidsgetrouwe of falsey-waarde). In plaats van te vergelijken foo, gewoon gebruiken als de voorwaarde, zoals deze:

    if (foo) // doe iets voor true else // doe iets voor false

    Om te testen vals, gebruik de logische operator NOT, zoals hieronder getoond:

    if (! foo) // doe iets als foo false is else // doe iets als foo waar is

    5 - Evenementbinding

    Evenementen zijn een ingewikkeld onderwerp in JavaScript. Voorbij zijn de dagen van inline bij klikken event handlers (behalve in enkele zeer zeldzame "splash page" -gevallen). Gebruik in plaats daarvan borrelen en delegeren van gebeurtenissen.

    Laten we ons voorstellen dat je een raster van foto's hebt die een modaal lightbox-venster moeten lanceren. Hier is wat jij moet niet do. Opmerking: we gebruiken jQuery hier, ervan uitgaande dat u een vergelijkbare bibliotheek gebruikt. Zo niet, dan gelden dezelfde bubblingprincipes ook voor vanille JavaScript.

    De relevante HTML:

    ...

    Het (slechte) JavaScript:

    $ ('a'). on ('klik', functie () callLightbox (this););

    Deze code gaat ervan uit dat bij het aanroepen van de lightbox een ankerelement wordt doorgegeven dat verwijst naar de afbeelding op volledige grootte. In plaats van binden aan elk ankerelement, binden aan de # Roostervormige houder element in plaats daarvan.

    $ ("# grid-container"). on ("klik", "a", functie (event) callLightbox (event.target););

    In deze code, beide deze en event.target verwijs naar het ankerelement. U kunt deze zelfde techniek gebruiken met elk ouderelement. Zorg ervoor dat u het element definieert dat het doel van de gebeurtenis moet zijn.

    6 - Vermijd Ternaire redundantie

    Het overmatig gebruik van ternaire statements komt vrij veel voor, zowel in JavaScript als in PHP.

     // javascript return foo.toString ()! == ""? waar onwaar;
     // php return (iets ())? waar onwaar;

    Een voorwaarde-expressie retourneert altijd a waar of vals waarde, wat betekent dat u niet expliciet hoeft toe te voegen waar/vals als ternaire waarden. In plaats daarvan kunt u eenvoudig de voorwaarde retourneren:

     // javascript return foo.toString ()! == "";
     // php retourneer iets ();

    PHP Tips

    7 - Gebruik Ternary wanneer dit van toepassing is

    als ... anders Verklaringen vormen een centraal onderdeel van de meeste talen. Maar iets eenvoudigs doen, zoals het toewijzen van een waarde aan een variabele op basis van een voorwaarde - nou, ze kunnen uw code onteren. Beschouw de volgende code:

    if ($ greeting) $ post-> message = 'Hallo';  else $ post-> message = 'Tot ziens'; 

    Deze code kan worden gereduceerd tot één regel, terwijl de leesbaarheid behouden blijft door de ternaire operator te gebruiken, zoals deze:

    $ post-> bericht = $ groet? 'Hallo tot ziens';

    Het is duidelijk, beknopt en biedt u de functionaliteit die u nodig hebt.

    Net zo nuttig als de ternaire operator is, is de belangrijkste richtlijn niet om deze te veel te gebruiken! Het doel van coderen is niet om je logica in zo min mogelijk regels te klemmen.

    8 - Gooi uitzonderingen in plaats van inception-style nesting

    Laten we eerlijk zijn: veel niveaus van nesten is lelijk en moeilijk te onderhouden / lezen. De volgende code is een relatief vereenvoudigd voorbeeld, maar ze worden in de loop van de tijd veel slechter:

     // anti-pattern $ error_message = null; if ($ this-> form_validation-> run ()) if ($ this-> upload-> do_upload ()) $ image = $ this-> upload-> get_info (); if (! $ this-> image-> create_thumbnail ($ image ['file_name'], 300, 150)) $ error_message = 'Er is een fout opgetreden bij het maken van de miniatuur.';  else $ error_message = 'Er is een fout opgetreden bij het uploaden van de afbeelding.';  else $ error_message = $ this-> form_validation-> error_string ();  // Toon foutmeldingen als ($ error_message! == null) $ this-> load-> view ('form', array ('error' => $ error_message,));  // Sla de pagina op anders $ some_data ['image'] = $ image ['file_name']; $ This-> some_model-> save ($ some_data); 

    Dat is een vervelende code, maar je kunt het drastisch schoner maken door uitzonderingen te gebruiken, zoals zo:

    probeer if (! $ this-> form_validation-> run ()) throw new Exception ($ this-> form_validation-> error_string ());  if (! $ this-> upload-> do_upload ()) gooi nieuwe uitzondering ('Er was een fout bij het uploaden van de afbeelding.');  $ image = $ this-> upload-> get_info (); if (! $ this-> image-> create_thumbnail ($ image ['file_name'], 300, 150)) throw new Exception ('Er is een fout opgetreden bij het maken van de thumbnail');  // Show error messages catch (Uitzondering $ e) $ this-> load-> view ('form', array ('error' => $ e-> getMessage (),)); // Stop de uitvoering van de methode met terugkeer of gebruik exit return;  // Zo ver gekomen, geen probleem $ some_data ['image'] = $ image ['file_name']; $ This-> some_model-> save ($ some_data);

    Het kan hetzelfde aantal regels zijn, maar het biedt aanzienlijk meer leesbare en onderhoudbare code. Het vermijdt ook die moeilijke foutopsporingssessies, waarbij je een mogelijk pad hebt gemist door de als uitspraak. Hou het simpel!

    Tweede mening: wees heel, heel voorzichtig, bij het gebruik van uitzonderingen voor stroomregeling. Raadpleeg hier voor aanvullende informatie.

    9 - vals-Happy Methods

    Uitzonderlijk gelukkig zijn is veel voordeliger dan vals-gelukkig zijn.

    Robijn- of Python-ontwikkelaars zijn gewend te kijken naar triviale uitzonderingen. Hoewel dat vervelend klinkt, is het eigenlijk best een goede zaak. Als er iets misgaat, wordt er een uitzondering gegenereerd en weet u meteen waar het probleem zit.

    In PHP - en vooral wanneer je oudere frameworks gebruikt, zoals CodeIgniter - krijg je wat ik noem "false-happy code" (in tegenstelling tot exception-happy). In plaats van een uitzondering in je hoofd te krijgen, geeft het gewoon een a terug vals waarde en wijst de foutreeks toe aan een andere eigenschap. Dit dwingt je om het uit de klas te vissen met behulp van een get_error (); methode.

    Uitzonderlijk gelukkig zijn is veel voordeliger dan vals-gelukkig zijn. Als er een fout optreedt in uw code (bijv .: kon geen verbinding maken met S3 om een ​​afbeelding te uploaden, of een waarde is leeg, enz.), Gooi dan een uitzondering. Je kunt ook specifieke soorten uitzonderingen gooien door de Uitzondering klasse, zoals zo:

    class CustomException verlengt uitzondering 

    Als u een aangepaste uitzondering maakt, wordt het debuggen aanzienlijk eenvoudiger.

    Tip 10 - Gebruik bewakingsclausules

    Het is normaal om te gebruiken als statements om het uitvoeringspad van een functie of methode te besturen. Het is verleidelijk om een ​​voorwaarde te testen en veel code uit te voeren wanneer de toestand resulteert waar, alleen om gewoon terug te keren in de anders uitspraak. Bijvoorbeeld:

     function someFunction ($ param) if ($ param == 'OK') $ this-> doSomething (); geef waar terug;  else return false; 

    Dit soort oplossing vertegenwoordigt echter een potentieel voor spaghetti-code. U kunt deze code gemakkelijker leesbaar maken door de voorwaarde om te keren. Dit is de betere versie:

    function someFunction ($ param) if ($ param! = 'OK') return false; $ This-> doSomething (); geef waar terug; 

    Is dat niet makkelijker te lezen? Het is een eenvoudige verandering die een groot verschil maakt in de leesbaarheid van uw code.

    Tip 11 - Gebruik terwijl voor Simple Iterations

    De voor loop wordt vaak gebruikt wanneer u bijvoorbeeld een teller nodig heeft. Hier is een eenvoudig voor lus:

    for (var i = 0; i < x; i++) … 

    Er zijn enkele zeer goede redenen om a te gebruiken voor loop, maar a terwijl loop kan beter zijn als je gewoon iets simpels nodig hebt, zoals dit:

     var i = x; terwijl ik--) … 

    Het werkt niet in elke situatie, maar het is een alternatief.

    Tip 12 - Houd methoden houdbaar

    Dit is gemakkelijk een van de meest voorkomende fouten gemaakt door nieuwkomers.

    Een methode is de werkeenheid van een object, en als u uw methoden beperkt tot een onderhoudbare grootte, is uw code gemakkelijker te lezen en te onderhouden. Bekijk de volgende monster-methode:

    class SomeClass function monsterMethod () if ($ weArePilots) $ this-> goAndDressUp (); $ This-> washYourTeeth (); $ This-> cleanYourWeapon (); $ This-> takeYourHelmet (); if ($ this-> helmetDoesNotFit ()) $ this-> takeAHat (); else $ this-> installHelmet (); $ This-> chekcYourKnife (); if ($ this-> myAirplain () == "F22") $ this-> goToArmyAirport (); anders $ this-> goToCivilianAirport (); $ This-> doel (); $ This-> bereiden (); $ This-> brand (); 

    Overweeg deze monstermethode te splitsen in kleinere, beschrijvende brokken, die elk verantwoordelijk zijn voor het uitvoeren van een goed geabstraheerde actie. Dit is gemakkelijk een van de meest voorkomende fouten gemaakt door nieuwkomers.

    class SomeClass function monsterMethod () if ($ weArePilots) $ this-> prepareYourself (); $ This-> tryHelmet (); $ This-> findYourAirport (); $ This-> fightEnemy ();  private function prepareYourself () $ this-> goAndDressUp (); $ This-> washYourTeeth (); $ This-> cleanYourWeapon (); $ This-> chekcYourKnife ();  private functie tryHelmet () $ this-> takeYourHelmet (); if ($ this-> helmetDoesNotFit ()) $ this-> takeAHat (); else $ this-> installHelmet ();  private function findYourAirport () if ($ this-> myAirplain () == "F22") $ this-> goToArmyAirport (); anders $ this-> goToCivilianAirport ();  private functie fightEnemy () $ this-> aim (); $ This-> bereiden (); $ This-> brand (); 

    Daar gaan we: schoner en gemakkelijker te debuggen!

    Stap 13 - Vermijd Deep Nesting

    Te veel nestniveaus maken code moeilijk te lezen en te onderhouden. Stel je de volgende situatie voor:

    function doSomething () if ($ someCondition) if ($ someOtherCondition) if ($ yetSomeOtherCondition) doSomethingSpecial ();  doe iets anders(); 

    U kunt Tip 10 raadplegen om deze code leesbaarder te maken door een aantal voorwaarden om te keren.

    function doSomething () if (! $ someCondition) return false;  if (! $ someOtherCondition) return false;  if ($ yetSomeOtherCondition) doSomethingSpecial ();  doe iets anders(); 

    Deze code is aanzienlijk schoner en geeft dezelfde resultaten als voorheen.

    Wanneer je merkt dat je genest bent als verklaringen, onderzoek uw code nauwkeurig; uw methode kan meer dan één taak uitvoeren. Hier is een voorbeeld:

    function someFunc () if ($ oneThing) $ this-> doSomething (); if ($ anotherThing) $ this-> doSomethingElse (); 

    In deze gevallen, pak de geneste methoden uit in hun eigen methode:

    function someFunc () if ($ oneThing) $ this-> doSomething (); $ This-> doAnotherThing ($ anotherThing);  private doAnotherThing ($ anotherThing) if ($ anotherThing) $ this-> doSomethingElse (); 

    Tip 14 - Vermijd magische nummers en snaren

    Magische cijfers en snaren zijn slecht. Definieer variabelen of constanten met de waarden die u in uw code wilt gebruiken.

    In plaats van dit:

    function someFunct () $ this-> order-> set (23); $ This-> order-> addProduct ( 'supercomputer'); $ This-> shoppingList-> toe te voegen ( 'supercomputer'); 

    Geef op wat die getallen en tekenreeksen betekenen en wijs ze toe aan een variabele met een betekenisvolle naam, zoals deze:

    function someFunct () $ orderId = 23; $ selectedProductName = 'superComputer'; $ This-> order-> set ($ orderId); $ This-> order-> addProduct ($ selectedProductName); $ This-> shoppingList-> toe te voegen ($ selectedProductName); 

    Hoewel sommigen misschien beweren dat we nodeloos variabelen maken, is de prestatieshit te verwaarlozen. De leesbaarheid heeft altijd voorrang. Let op: optimaliseer niet voor prestaties totdat u kunt beschrijven waarom dit nodig is.

    Stap 15 - Gebruik ingebouwde array-functies

    Gebruik de ingebouwde array-functies in plaats van foreach ().

    Niet ideaal:

    foreach (& $ myArray als $ key => $ element) if ($ element> 5) unset ($ myArray [$ key]); 

    Beter:

    $ myArray = array_filter ($ myArray, function ($ element) return $ -element <= 5;);

    PHP biedt verschillende matrixmethoden. Ze zijn in het begin verwarrend, maar nemen een dag en proberen zoveel mogelijk mensen te leren kennen.

    Tip 16 - Gebruik variabelen niet te veel

    Het is gemakkelijk om variabelen te veel te gebruiken, maar houd er rekening mee dat variabelen in het geheugen worden opgeslagen. Voor elke variabele die u maakt, moet het systeem geheugen voor die variabele toewijzen. Kijk naar deze code:

    openbare functie get_posts () $ query = $ this-> db-> get ('posts'); $ result = $ query-> result (); return $ resultaat; 

    De $ result variabele is niet nodig. De volgende code laat die variabele weg:

    openbare functie get_posts () $ query = $ this-> db-> get ('posts'); return $ query-> result (); 

    Het verschil is subtiel, maar we hebben dit eenvoudige voorbeeld kunnen verbeteren. We hebben het $ vraag variabele omdat het betrekking heeft op de database, terwijl $ result meer te maken met onze logica.


    Algemene programmeringsaanbevelingen

    Tip 17 - Vertrouw op de database-engine

    Alles minder is een codegeur.

    Een database is ontworpen voor het werken met gegevens; gebruik de hulpmiddelen en mogelijkheden om uw toepassing efficiënter te maken.

    U kunt bijvoorbeeld in veel omstandigheden overbodige databasequery's vermijden. De meeste plug-and-play gebruikersbeheerscripts gebruiken twee query's voor gebruikersregistratie: één om te controleren of de e-mail / gebruikersnaam al bestaat en een andere om deze daadwerkelijk aan de database toe te voegen. Een veel betere benadering is om het veld gebruikersnaam in te stellen UNIEK. U kunt dan de ingebouwde MySQL-functies gebruiken om te controleren of de record aan de database is toegevoegd.

    Tip 18: geef een goede naam aan uw variabelen

    De dagen van het benoemen van uw variabelen X, Y, z zijn voorbij (tenzij je natuurlijk te maken hebt met een coördinatenstelsel). Een variabele vertegenwoordigt een belangrijk onderdeel van uw logica. Wilt u geen lange naam typen? Krijg een betere IDE. Moderne IDE's vullen variabele namen automatisch aan in een oogwenk.

    Altijd vanaf nu zes maanden coderen. Weet je zeker dat je je dat zult herinneren? $ sut variabelen verwijst naar een jaar vanaf nu? Waarschijnlijk niet: beschrijvend zijn. Alles minder is een codegeur.

    Tip 19 - Methoden vertegenwoordigen acties

    Fouten gebeuren; de sleutel is om van hen te leren.

    Geef je methoden een naam met werkwoorden die de actie vertegenwoordigen die ze uitvoeren. Het hoofdconcept is precies het tegenovergestelde van het variabel naamgevingsschema. Gebruik een korte, maar beschrijvende naam in een groot bereik (dat wil zeggen: openbare methoden) en gebruik een langere en meer gedetailleerde naam in een korte scope (dwz: private / beschermde methoden). Dit helpt uw ​​code te laten lezen als goed geschreven proza.

    Vermijd ook een andere taal dan het Engels, bij het benoemen van uw methoden. Het is vervelend om functienamen zoals 做些 什麼 () of делатьчтото () in uw project te lezen. Het kan voor andere programmeurs onmogelijk zijn om uw bedoeling te begrijpen. Hoewel het misschien arrogant lijkt, is het Engels de goede programmeertaal. Probeer het te gebruiken, als we aan een groot team werken.

    Tip 20: Structuuraanbevelingen

    Ten slotte is de codestructuur net zo belangrijk voor de leesbaarheid en onderhoudbaarheid als al het andere waar we het vandaag over hebben gehad. Hier zijn twee aanbevelingen:

    • Inspring met vier of twee tabbladen met breedte van de breedte. Iets meer, zoals acht spaties, is te veel en maakt je code moeilijk leesbaar.
    • Stel een redelijke lijnbreedte in en respecteer het. Veertig tekens in een rij? We zijn niet meer in de jaren '70; stel je limiet in op 120 tekens, zet een markering op het scherm en dwing jezelf of je IDE om die limiet te respecteren. 120 tekens geven je een mooie breedte zonder dat je hoeft te scrollen.

    Conclusie

    "Ik heb nog nooit een stomme programmeerfout gemaakt." -- Niemand ooit.

    Fouten gebeuren; de sleutel is om van hen te leren. Wij van Nettuts + hebben fouten gemaakt en zullen dat ook blijven doen. We hopen dat u van onze fouten leert, zodat u ze in de toekomst kunt vermijden. Maar om eerlijk te zijn, de beste manier om beste praktijken te leren, is door zelf fouten te maken!

    Bedankt voor het lezen!