Leave It Better Than How You Found It
What’s something that’s been confusing? How would you explain it to someone else?
Functions. Functions, and maybe even some more… functions. Functions are confusing to me, did I mention that? Here’s how I would explain it, just like I would to someone else, and hopefully by doing so I can grasp a clearer understanding of one of the main components of JavaScript.
First, let’s define the term function. As stated by W3Schools, a function is a block of code designed to perform a particular task. The function is then executed when “something” invokes it or calls it.
Let’s take a closer look at the Anatomy of a Function and break it down to its smaller components.
const addTwoNumbers = (x, y) => {
return x + y;
}
addTwoNumbers(3, 4);
- const declares a variable named addTwoNumbers
- = tells us that the variable is going to hold a parameter,
- or in this case, two parameters in the parentheses (x, y)
- => this fat arrow points to the function body which is surrounded by {}
- the body of the function is return x + y
- addTwoNumbers(3, 4) this is the function being called beginning with the function name, and inside the parentheses 3, 4 are the arguments or values passed to the function when it is called
A note to take away: functions always need to return something. They need to do something, carry out an operation of some kind which returns a result.
Hopefully, this explanation helps… me and you.
What is the “use strict”;? What are the advantages and disadvantages of using it?
Here’s to being a stickler. The “use strict” mode or directive, compared to normal JavaScript, was new in ECMAScript version 5. Essentially, it helps a developer write cleaner code by being strict and not allowing undeclared variables to be read due simply to misspelling for example. Instead, because it is strict, an error will be thrown, preventing the declaration of a global variable. That’s an upside.
A downside to “use strict” is when a variable is declared within another function or scope and used from somewhere else, the code will break if it can’t be rewritten or changed before being declared with a strict directive.
Ultimately though, “use strict” has a lot of positives when it comes to composing good syntax and catching errors.
“Without standards, there can be no improvement.”
— Taiichi Ohno
Explain function hoisting in JavaScript.
Hoisting functions in JavaScript is when a function is moved to the top of its scope before code execution. This means that no matter where the function is placed if it’s a named function, they are moved to the top regardless of either belonging to a local or global scope. One way to avoid function hoisting is to store an unnamed function inside a variable, and store the needed variables for the unnamed function, within the function body instead of outside. This prevents the variables for a function from being hoisted as well.
Explain the importance of standards and standards bodies like ECMA.
Japanese Industrial Engineer, Taiichi Ohno once said, “Without standards, there can be no improvement.” Before explaining the importance of standards and standards bodies like ECMA (European Computer Manufacturers Association), let’s define some key terms to ensure that we’re clear on everything.
We’ll begin by defining a web standard. A web standard is a specification of web technologies. Okay, so what’s a specification? According to MDN, a specification is “a document that lays out in detail what functionality or attributes a product must include before delivery.” So what does that mean? In an article for Stack Overflow, author Zara Cooper notes that a technical specification document outlines how developers are going to address a technical problem by designing and building a solution for it. With this explanation, we can safely say that a specification document is a written overall plan, that helps transform an idea into something concrete written down, getting all parties involved, literally on the same page.
So if a specification for web technology, like plans for building a shopping app or fitness tracker, shows how and what is going to be built, then a specification for languages such as ECMAScript is a standard of how the language should be written. Web standards were actually brought to the forefront with HTML 4.0 and CSS-1. With these standards, the mayhem of websites being displayed differently in all versions of browsers was on its way to being eradicated.
With a collaborative craft such as web development, it’s crucial to maintain web standards to build and often continue a working product. It helps developers and team members produce a successful project, and ensures a smooth experience for the company and its users because it’s uniformed to fit an ever-changing platform of browsers and devices.
What actions have you personally taken on recent projects to increase the maintainability of your code?
As author Mahdi Rezvi contends in his article “JavaScript Best Practices for Readable and Maintainable Code,” developers spend more time reading code than they do writing code. We can even go further and say that re-reading our own code is included. In order to increase the maintainability of my code, I’ve tried to be as specific as possible so that I clearly understand what is being written, what is trying to be achieved, and that other developers can jump in and collaborate with ease. Some of these principles include creating meaningful names for variables and functions, step by step pseudocode, notes in the pseudocode and README files that include the project’s overall design and challenge areas, and finally trying to dry up as much code as possible.
Hopefully, by developing good habits and instilling them into my process as a developer and communicator, my contributions towards a project can help a team maintain an efficient and positive environment.
Why is it, in general, a good idea to leave the global scope of a website as-is and never touch it?
There’s a clear understanding in theatre, film, and television concerning jobs, the chain of command, and even specifically props. In fact, it’s not even an understanding so much as legality. If it’s not your prop, don’t touch it. There are union workers, it’s their job, they’re responsible for it and if anything happens to said prop, it’s their responsibility and they take the fall. So, don’t touch the props. There’s even a story I was told about an incident on SNL long ago.
During a rehearsal with a crowd of actors, the director, and the crew, an actor loses their finger and the appendage falls to the floor. Everyone stops, a mess is starting to be made, the actor is taken to a sink, and all eyes are on the finger. No one moves. Meanwhile, a custodian comes in, cleans up the spill but leaves the finger alone. Someone asks him, “Aren’t you going to pick up that finger?”.
The custodian without batting an eye says, “Nope, that’s props.”
What does this have to do with the global scope? Don’t touch it. It creates confusion. Developers that you’ve never met before, most likely spent some quality time in meetings and writing up that code and with the flick of a keystroke, someone throws a global variable outside of the function or forgets using the keywords let, const, or the archaic var and then you find there’s a problem with the phalange. Here’s a great article for reference on global scopes by Lucy Bain.
