We are just an advanced breed of monkeys on a minor planet of a very average star. But we can understand the Universe. That makes us something very special.
Stephen Hawking
Understanding our Javascript environment
Javascript syntax, the way we write our scripts telling the computer what to accomplish. Understanding how the environment works help us write clean efficient code, and who doesn't like to have nice and clean code? It gives me a headache when I run into a messy code of mine and didn't really properly indent or space out my code in a very friendly manner. This will be multiple guides so there will be parts to it as they build on top of each other. In this topic, we will go over identifiers, keywords, comments, & semicolons. Very basic stuff but powerful knowledge that at some point in the future when debugging you will thank yourself for knowing how to read the lines of code to figure out what does what and what controls what.
Identifiers & Keywords
When we declare a variable with a name, that is simply the identifier. Yes, an identifier is literally the name of our variables, functions, classes, and properties. That is really it, the other part is they can start with either a Letter, $ (dollar sign), or (_) underscore.
var
_myVar
my_Var
$var
But like any other language, there are reserved words in the javascript, and these words are not allowed to be used as identifiers. When we begin to write our code, we need to always be aware of how we are naming our variables or functions, etc. why? Javascript already has some reserved identifiers and functions that are built-in to the language that allows us to do more when working with data. So we don't have to come up with basic algorithms that someone already has done for us. With that being said, that does not mean you can't create your own algorithms, it just means someone else took the liberty to create it for us so we can simply use these functions in our scripts to do more complex algorithms.
For example when using the built-in if/else statement we HAVE to type it out like so
if (x === y) {
return z
} else () {
return false
}
We can't have a capitalized If or Else, IF/ELSE, etc. Javascript will not know what you are trying to do and throw us an error about the syntax not being typed out correctly. So what does this mean overall? Javascript is case sensitive so you have to be very careful on what you name your variables, classes, functions, properties, keywords, etc.
With that being said we don't have to worry too much about spaces though. Because you can use spaces and newlines any way you like. But it comes with a cost, not having clean readable code can make it harder for others to understand what the script is supposed to accomplish. Of course, if you write the script you will know what it does since you wrote it, but what if you needed help or got stuck and needed someone else to view it, they will then have a harder time trying to read your code and then on top of that having to try to solve the problem, that doesn't help us get closer to the solution faster. So when it comes to spacing, there is a standard rule of 2 spaces or 4 spaces when it comes to indenting. It is up to you how you decide to space out your code or in your workplace. Javascript has the ability to see through the spaces, newline breaks, and more.
Reserved Keywords
As I've stated previously Javascript has a couple of reserved keywords, what does this mean? It means that these words are part of the Javascript language. Some of these can not be used as constants, variables, functions, or classes. All of this is retain backward compatibility, something we don't need to get into depth unless you are working with really big projects that have to worry about old devices that others may still be using.
Here is a list of those reserved keywords.
as const export get null target void
async continue extends if of this while
await debugger false import return throw with
break default finally in set true yield
case delete for instanceof static try
catch do from letting super typeof
class else function new switch var
Either get busy living or get busy dying
Steven king
How to work with comments
Ever had a moment when you work on a project, take a break due to a bug, come back after a few hours and have no idea where you left off? What is the reason for comments when it comes to writing our code? Comments can be a lifesaver not just for others viewing your code but for yourself when you go back to your code after a few days. Commenting is huge, but don't just comment on anything, make them meaningful. Explain what your code is doing if you have to, not by being direct on what the function is supposed to output, but what every line of code is expected to do. There are only two ways to write out comments in our Javascript code. Anything nested within /* */ is considered a multiline comment, anything that is after // two forward slashes is also a comment but the major difference is that it is a single-line comment, anything after the breaking will be considered code in the lexical environment.
Example of comments in a javascript:
“// This is a single-line comment.
/* This is also a comment */ // and here is another comment.
/*
* This is a multi-line comment. The extra * characters at the start of
* each line is not a required part of the syntax; they just look cool!
*/”
Is it helpful to know semicolons?
Semicolons, one of many things that we talk about a lot in javascript, do they matter because they help us read code better? Do they not help us at all? Why do we need to worry about them? Well, to begin with, semicolons are a very important thing to get very familiar with and understand how it truly works in the javascript language. When working with semicolons sometimes you may notice you may leave it out of a statement and your code works fine. But there are actually reasons why this happens in our code. Let me explain a bit more in-depth, we really use them to separate statements. If a statement does not have a separator it can confuse the javascript interpreter and think it's part of the first statement, we need them to mark the end of our statement being made.
a = 1; // putting a semicolon here tells our interpter that we
b = 2; // end our first statement and want to assign another
// or when we use the return statement
return // having a line break here javascript will assume
true; // there is a semicolon at the end of the first and
return; true; // the interpreter assumes this instead
return true; // but this is what actually want
Javascript will assume that break lines after statements are semicolons at times. If you do use a line break after a return statement your code is most likely to have bugs that are not very visible.
Conclusion
I hope by the end of this article you managed to learn how to create and understood what is going on in every line of code. It is very important to understand how your code fully works, not only does it help you become a better developer but can also help you use the tools you are working with more efficiently.
These articles are mostly intended for personal use on becoming a better programmer, writer, and grow my programming skills. Feel free to drop any feedback or corrections that you believe should be made to help me and others. Thank you for your time in sticking this far!
Feel free to give me a follow on Twitter and get connected on LinkedIn.
Top comments (0)