I’ve Cracked the Code, Please Call Tech Support- Episode 9, The Rise of JavaScript Writing

Moving right along! We have a few basic games in our repertoire now, and the basics of JavaScript continue to grow. In addition to our class material I’ve been reading as many books on JavaScript as I can, and it’s really been helpful. Sometimes it’s just down to “I can’t stare at this computer any more, please give me a book, please.”

  1. Describe one thing you’re learning in class today.

I’m learning more about how to work with objects in JavaScript, which is very helpful. In a web document, an “object” can have many attributes. Let’s say that you want to store some user information for your website. Well, you could have multiple arrays of info (which could be tough to piece together), OR you could have a number of items, that each contain multiple values. So, you end up with something like:

const User ={

firstName: “John”,

lastName: “Doe”,

age: 25,

height: 6',

};

Our one object (User), now contains all of that information, which can be called upon individually. Pretty rad.

2. What is “use strict”;? What are the advantages and disadvantages to using it?

JavaScript, for all its positives, can be a little loosey-goosey when it comes to code implementation. So, we’ve got a declaration called “use strict”, which tightens up its interpretations a bit.

With “use strict”, you can’t use undeclared variables. So, you can’t have any unknown numbers just floating about in your code. This makes you a better coder, because your code has to be correct, or JavaScript’s going to go “What is this? I can’t read this. You are being silly.” The downside being, of course, your code has to be correct.

3. Explain function hoisting in JavaScript.

Remember how I mentioned that JavaScript was a little loosey-goosey? hoisting is an example of how that’s really helpful.

In most code, you can’t call a function before you define it. That just makes sense, you have to know what a thing does before you can do it.

Not so with JavaScript! In JS there is a thing called hoisting, wherein it puts all function declarations into memory before it executes any code segment. This means that where-ever you define it, JavaScript will find it. But it should still be neatly laid out so that other humans can read it, too. Please.

4. Explain the importance of standards and standards bodies like ECMA.

Standards are very important to maintain. These are the official specifications that define how websites are built. You can probably imagine how disjointed the internet would become if it was just the wild west of development, with everyone trying to set their own standards of design.

On that same note, bodies like the ECMA (European Computer Manufacturers Association) works to establish and facilitate these standards throughout the industry. Having groups of people work on a standardized system based on consensus is really the way to go in this case.

5. What actions have you taken on recent projects to increase maintainability of your code?

I believe that I’ve hit this point on previous blogs, but honestly commenting code is the best thing that you can do to maintain everything. Break down your sections, comment why this exists, use semantic language for your classes and tags. If other people can read your code and understand it, you’re in a great position to maintain it. Keep it simple, and when you can’t, keep it commented.

6. Why is it, in general, a good idea to leave the global scope of a website as-is and never touch it?

In coding, you can set something called a “global variable”. This…isn’t great to do. Because it’s a global variable, everything can access it. While this might sound appealing at the outset, in practice it tends to gum up the works. You get conflicts of code (trying to create new, local variables that get interfered with), and since it’s a global variable, anyone on any point in the program can update it at any time, potentially causing a bit of chaos.

Overall, its just poor coding practice in general. It looks bad, it performs poorly at best. Code a local variable every change you get, never code a global one.