Juist gebruik van const voor het definiëren van functies

Zijn er limieten aan de soorten waarden die kunnen worden ingesteld met constin JavaScript, en in het bijzonder aan functies? Is dit geldig? Toegegeven, het werkt, maar wordt het om welke reden dan ook als een slechte gewoonte beschouwd?

const doSomething = () => {
   ...
}

Moeten alle functies op deze manier worden gedefinieerd in ES6? Het lijkt erop dat dit niet is aangeslagen, als dat zo is.


Antwoord 1, autoriteit 100%

Er is geen probleem met wat je hebt gedaan, maar je moet het verschil onthouden tussen functiedeclaraties en functie-expressies.

Een functiedeclaratie, dat wil zeggen:

function doSomething () {}

Wordt volledig naar de top van de scope gehesen (en net als leten constzijn ze ook block-scoped).

Dit betekent dat het volgende zal werken:

doSomething() // works!
function doSomething() {}

Een functie-uitdrukking, dat wil zeggen:

[const | let | var] = function () {} (or () =>

Is het maken van een anonieme functie (function () {}) en het maken van een variabele, en vervolgens de toewijzing van die anonieme functie aan die variabele.

Dus de gebruikelijke regels rond het hijsen van variabelen binnen een scope — block-scoped variabelen (leten const) niet hijsen als undefinednaar de top van hun blokbereik.

Dit betekent:

if (true) {
    doSomething() // will fail
    const doSomething = function () {}
}

Mislukt omdat doSomethingniet is gedefinieerd. (Het geeft een ReferenceError)

Als je overschakelt naar het gebruik van var, krijg je het hijsen van de variabele, maar deze wordt geïnitialiseerd op undefinedzodat het bovenstaande codeblok nog steeds niet werkt. (Hierdoor wordt een TypeErrorgegenereerd omdat doSomethinggeen functie is op het moment dat je het aanroept)

Voor zover het de standaardpraktijken betreft, moet u altijd de juiste tool voor de klus gebruiken.

Axel Rauschmayer heeft een geweldige post over reikwijdte en hijsen, inclusief es6-semantiek: Variabelen en scoping in ES6


Antwoord 2, autoriteit 46%

Hoewel het gebruik van constom functies te definiëren een hack lijkt, heeft het enkele grote voordelen die het superieur maken (naar mijn mening)

  1. Het maakt de functie onveranderlijk, dus je hoeft je geen zorgen te maken dat die functie wordt gewijzigd door een ander stukje code.

  2. U kunt de syntaxis van de dikke pijl gebruiken, die korter is & schoner.

  3. Het gebruik van pijlfuncties zorgt voor thisbinding voor u.

voorbeeld met function

// define a function
function add(x, y) { return x + y; }
// use it
console.log(add(1, 2)); // 3
// oops, someone mutated your function
add = function (x, y) { return x - y; };
// now this is not what you expected
console.log(add(1, 2)); // -1

Snippet uitvouwen


Antwoord 3, autoriteit 16%

Het is drie jaar geleden dat deze vraag werd gesteld, maar ik kom hem nu pas tegen. Aangezien dit antwoord zo ver beneden de stapel ligt, staat u mij toe het te herhalen:

V:Ik ben geïnteresseerd als er grenzen zijn aan wat voor soort waarden kunnen zijn
instellen met const in JavaScript, in het bijzonder functies. Is dit geldig?
Toegegeven, het werkt, maar wordt het voor niemand als een slechte gewoonte beschouwd
reden?

Ik was gemotiveerd om wat onderzoek te doen na het observeren van een productieve JavaScript-codeur die altijdconst-statement gebruikt voor functions, zelfs als er geen duidelijke reden/voordeel.

Als antwoord op “wordt het om welke reden dan ook als een slechte praktijk beschouwd?” wil ik zeggen: IMO, ja, dat is het, of er zijn in ieder geval voordelenaan het gebruik van functionstatement.

Het lijkt mij dat dit grotendeels een kwestie van voorkeur en stijl is. Er zijn hierboven enkele goede argumenten, maar geen enkele is zo duidelijk als in dit artikel wordt gedaan:

Constante verwarring: waarom ik nog steeds gebruik JavaScript-functieverklaringenvan medium.freecodecamp.org/Bill Sourour, JavaScript-goeroe, consultant en leraar.

Ik dring er bij iedereen op aan dat artikel te lezen, zelfs als je al een beslissing hebt genomen.

Dit zijn de belangrijkste punten:

Functie-statements hebben twee duidelijke voordelen ten opzichte van de functie [const]
uitdrukkingen:

Voordeel #1: Duidelijke intentie

Bij het doorzoeken
duizenden regels code per dag, het is handig om erachter te komen
de bedoeling van de programmeur zo snel en gemakkelijk mogelijk.

Voordeel #2: Volgorde van aangifte == volgorde van uitvoering

Idealiter wil ik mijn code min of meer aangeven in de volgorde waarin ik
verwacht dat het wordt uitgevoerd.

Dit is de showstopper voor mij: elke waarde gedeclareerd met de const
zoekwoord is niet toegankelijk totdat de uitvoering het bereikt.

Wat ik hierboven heb beschreven, dwingt ons om code te schrijven die eruitziet
ondersteboven. We moeten beginnen met de functie en het werk op het laagste niveau
onze weg naar boven.

Mijn brein werkt niet op die manier. Ik wil de context vóór de details.

De meeste code is door mensen geschreven. Het is dus logisch dat de meeste mensen
volgorde van begrip volgt ruwweg de volgorde van uitvoering van de meeste code.

Other episodes