DEV Community

Cover image for JavaScript (Lexical Structure)
Clean Code Studio
Clean Code Studio

Posted on • Updated on

JavaScript (Lexical Structure)

Twitter Follow

Did you know I have a newsletter? 📬

If you want to get notified when I publish new blog posts or
make major project announcements, head over to
https://cleancodestudio.paperform.co/


The Lexical Structure of a software language:

"Specifies a set of basic rules defining how code should or could be written"

As one of the world's most misunderstood programming language as well as a software language with some weird oddities, there are many questions that come up about what is best practice when it comes to writing JavaScript. In this blog we're going to dive into the Lexical structure of JavaScript. Lexical Structure simply specifies a set of basic rules defining how code should be written in a given language.


Unicode


JavaScript is written in Unicode. What's this mean? Well, one of the cool, lesser used, and generally considered a poor or bad practice is that we can actually use emojis as variable names. We can use emojis as variable names because JavaScript is written in Unicode. More importantly, you can write identifiers in any language, for example, Japanese or Chinese, with some rules.


Optional Semicolon


In JavaScript (and most other languages) the semicolon is used to separate one given statement from another. What's weird about JavaScript is that this semi-colon is optional. Personally, I opt out of using the semi-colon and just write my statements on two separate lines. Any two statements that are written on the same line will always need to utilize a semi-colon to separate them - but this in itself is considered bad practice.


Whitespaces and Line Breaks


In JavaScript, white space is NOT considered as anything meaningful. Spaces and line breaks can be added as you see fit.

For example


axios.get(endpoint)
.then(response => console.log(response))
.catch(errors => console.error(errors))

Enter fullscreen mode Exit fullscreen mode

can also be written as


axios

.get(endpoint)
.then(response => console.log(response))
.catch(errors => console.error(errors))

Enter fullscreen mode Exit fullscreen mode

or as

axios

.get
(endpoint)

.then
(response => console.log(response))

.catch
(errors => console.error(errors))
Enter fullscreen mode Exit fullscreen mode

JavaScript doesn't care about the white space. Personally, I'll go about the former statement using the following syntax.

axios.get(endpoint)
     .then(response => console.log(response))
     .catch(errors => console.error(errors))
Enter fullscreen mode Exit fullscreen mode

In the real world, you'll definitely want to keep a well-defined style and adhere to that commonly used style. You can and in larger project should enforce this style using a linter or a styling tool like Prettier.


Case Sensitive


JavaScript is case sensitive. What's this mean for a software language? If you have two variables spelling the same word and one is capitalized while the other is not - then these are considered two different variables.

let helloWorld = 'example'
let HelloWorld = 'heyooo'
Enter fullscreen mode Exit fullscreen mode

HelloWorld and helloWorld are two different variables because JS is case sensitive.

Keywords, variables, function names, and other identifiers must always be typed with a consistent capitalization of letters to be or mean the same thing.


Comments


Good old comments. In JavaScript we have two types of comments we can utilize or call upon to add notes that are functionally meaningful within our code.

Single Line Comments

// this is a single line comment
Enter fullscreen mode Exit fullscreen mode

Multiple Line Comments

/*
  This is a multiple line
  comment that we can
  use to write a lot 
  of stuff when
  we need to.
*/
Enter fullscreen mode Exit fullscreen mode

Literals and Identifiers


Literals are defined as a value that is written within the source code.

For example, a string, a number, a Boolean, an object literal, or an array literal are all literals.


10 // a number literal
true // a Boolean literal
'hey' // a string literal
[1, 2] // an array literal
{ name: 'sarah' } // an object literal
Enter fullscreen mode Exit fullscreen mode

An identifier is simply a sequence of characters used to identify a variable, function, or an object. An identifier can start with a letter, dollar sign ($), underscore (_), and may also contain digits. Using unicode, a letter can be considered any allowed char - thus we can also use an emoji. Another way to understand what an identifier means is to simply ask yourself what allowed variables names can I use in this language.

Name
name
NAME
_name
$name
😄
Enter fullscreen mode Exit fullscreen mode

Are all allowed variable names - aka allowed identifiers within JavaScript.


Reserved Words


Most (if not every) software language has a list of reserved words. These reserved words do special things that allow the software language to work properly. In JavaScript we have a list of Reserved Words that are not allowed to be used as identifiers due to the language saving these words to implement special functionality.

Some Reserved Words in JavaScript include:

  • abstract
  • arguments
  • boolean
  • break
  • byte
  • case
  • catch
  • char
  • class
  • const
  • continue
  • debugger
  • default
  • delete
  • do
  • double
  • else
  • enum
  • eval
  • export
  • float
  • extends
  • false
  • function
  • final
  • goto
  • if
  • finally
  • float
  • implements
  • yield
  • import
  • in
  • instanceof
  • int
  • interface
  • let
  • package
  • private
  • lang
  • native
  • new
  • null
  • protected
  • public
  • return
  • short
  • static
  • super
  • switch
  • synchronized
  • this
  • throw
  • throws
  • transient
  • true
  • try
  • typeof
  • var -void
  • volatile
  • while
  • with

Note, that not all reserved words do something within JavaScript currently. Many of these reserved words are simply marked as unusable by the language so that future versions of JavaScript where these reserved words add behavior to JavaScript won't cause legacy applications of JavaScript programs to break or need to be changed because they used the keywords that now do something as identifiers before these keywords were able to do anything within JS.


Clean Code
Clean Code Studio
Refactoring Code
Computer Science Algorithms
Data Structures - JavaScript
Design Principles


Did you know I have a newsletter? 📬

If you want to get notified when I publish new blog posts or
make major project announcements, head over to

Top comments (1)

Collapse
 
cleancodestudio profile image
Clean Code Studio