On writing JavaScript well.

How the wrong words can trigger unintended reactions, whether in life or in code.

Contemplating the meaning of what a variable represents can lead to code that reads how you think about it. It can decrease the time necessary to comprehend and help avoid erroneous assumptions.

Reading code out loud is a great way to find areas where the code is difficult to understand. You'll learn two techniques, reading line by line and summarizing and how they both can give perspective on naming.

Watch out for words that are a red flag that indicate a lack of meaning in a name. We'll talk about the common red flags to watch out for and how you can go about adding meaning.

Abbrs. adds a sig amt of ovrhd to undrstdng code.

Method names are just as important as variable names. We'll talk about how to approach naming a method by putting yourself in the shoes of the consumer of the method and how to separate what from how when naming the method.

Many languages have naming conventions that convey information about scope, we'll talk about scope in JavaScript and whether or not you should include a naming style with indications of scope.

A ubiquitous naming convention to help running into problems with constructor functions in JavaScript.

Naming constants to indicate that they are constant and whether or not this is a good idea in JavaScript.

No doubt you've seen hungarian notiation in action, we'll review what it is and the impact of adding type information into variable naming.

Being careful what you write in code, it can come back to bite you! This includes how things are named.

Translating concepts and abstractions that don't align with the purpose of what the code accomplishes can obscure what code does and bleed into every day conversation.

Sometimes it helps to be explicit in how we name things, even to introduce variables to enhance the clarity of code. This is a nice way to make what otherwise might be a comment, explicit in the code itself.

A common problem with variables that represent multiple "items" and the consequences of a simple mishap in naming.

One of the best ways to learn is to apply learning in a generative approach. I've provided a sample bubble sort implementation in JavaScript. Take the example and try using the techniques discussed in this section to give more meaningful naming to the implementation and to help yourself, and others, better understand how the implementation works.

This lecture covers how I approached naming and meaning in the bubble sort algorithm. There's no right answer, I just wanted to provide some food for thought, leveraging many of the techniques of this course to demonstrate how they play together to transform code for the better.

If you opened a book and the table of contents were garbled because of inconsistency in structure, would you want to read the book? Would you want to read code that wasn't structured well?

An introduction to how you can leverage indentation, spacing, braces and other structural aspects of code to add clarity. We'll walk through a garbled function and add some clarity manually.

Structural formatting makes a big difference but applying structural consistency by hand is a nightmare. Learn how tools can help at the push of a button. We'll look at cleaning up the same example as in the last clip, with WebStorm.

The best of tools allow us to customize the structural rules we want to apply. We'll start out talking about how to leverage customization in WebStorm and look first at indentation.

Spacing is another dimension of structure that can add clarity. It can add horizontal partitioning to segment the components of simple aspects like variable assignment. Poor and especially inconsistent attention to spacing can make code hard to follow. We'll look at the nuances of the many rules one can apply with spacing and briefly discuss tradeoffs.

Braces can help set apart a section of code by adding a layer of nesting and indentation. Line wraps can reduce the amount of information on any one line of code, especially when initializing objects. This lecture looks at some settings associated with each and the resulting impact.

Long lines of code lead to lines that trail off the screen and require lots of scrolling while you read through the code, and perhaps missing important aspects that are off the screen, or require wrapping by the editor which can also be confusing. By leveraging your editor to indicate when a line is getting too long, you can intentionally modify the code to explicitly add wrapping where it makes the most sense to avoid ambiguity.

What would you think if a book randomly separated paragraphs by 1, 2, 3 or more blank lines? It probably would be a distraction. The same is true in code. Fortunately, editors can help remove excessive blank lines.

Code styles settings, especially structural settings, are great for individuals to automatically clean up code, but it would be a hassle to get everyone to configure each setting to match. And then switch settings every time they switch projects, where settings may differ. It's possible, with some tools, to share a single set of settings through version control.

Parenthesis are a tool you can use to add explicit clarity to code. And at the same time, if abused, can cause confusion.

Alright, so we've covered a lot about the importance of naming and structure, you'll need to leverage both components to make some sense of the following example, and give it more meaning in the process.

Here's what I changed in the previous hands on example, leveraging both naming and structural aesthetics.

Comments play a crucial role in making code understandable, but there's a fine line that's easy to cross.

I'm sure you've stumbled upon plenty of code where the comments don't seem to add much understanding and rather seem repetitive of what's already obvious in the code itself. Or perhaps what's already not obvious about the code itself :)

What are the advantages and disadvantages of adding comments to the end of a line of code?

Comments are an alternative means of adding understanding to the code itself, comments often cross the line and encourage comments in lieu of more meaningful naming.

Sometimes comments delineate sections of code that can be extracted into separate, perhaps reusable functions.

Problems with the code itself, even the understand-ability of the code itself, are often addressed with comments to explain what isn't obvious. This serves as an opportunity to make enhancements to the code itself instead of relying on comments as a crutch.

Before version control was rather ubiquitous, comments served to leave behind old versions of the code. But they were a really poor means of tracking the history of a code base. Unfortunately, to this day, many code bases still contain relics of old versions of their code in commented out code.

Comments can play an important role in explaining to consumers how to use a function. Comments can help them understand what they're getting into and in the case of JavaScript and JSDoc can help them catch mistakes.

Comments can help leave a permanent note about why a decision was made, that just can't be made obvious in the code itself. Without this important note, someone else may change the code without that understanding. Of course there are other tools to help avoid this, but comments of tradeoffs can be a first line of defense.

Coding is a naturally branching process, ideas come to mind, exceptional situations arise, sometimes we can't deal with them immediately but we would like to come back to them at some point. A sticky note is a great way to do this, but can easily be lost. We can leave sticky notes in our code with todo comments and our editor can help us track these down and come back to them when the time is right.

If comments are important enough to exist to explain something in code, then the contents of the comments should be treated with the same level of respect one write a book or an article and hopefully the same level of care being applied in crafting the code itself.

Those doozies of a comment that start out the beginning of every file of code in a code base. What are they, why do they exist, and do we really need them?

Alright, so we've covered a lot about the importance of comments, naming and structure, you'll need to leverage all of these to make some sense of the following example.

You'll learn how to install WebStorm, clone the samples for this course and how to browse through the files in the samples.

You'll learn how to find your way around WebStorm, basics like the menu, tool windows and most importantly how to instantly search and find any action in WebStorm.

Navigating code can be a nightmare, nobody likes to poke around in files and folders. You'll learn how to use WebStorms search capabilities to find exactly the piece of code you want, instantly. This helps when you're working to improve code and you need to navigate through the code base to understand it.

Running code is the best way to see what happens, right!

As you work to improve code, having the ability to quickly massage, or refactor code, is invaluable. WebStorm is loaded with powerful refactorings to help you out. You'll learn how to access refactorings and we'll specifically talk about renaming, which should help with all the techniques you learned in the first section on meaningful naming.

EditorConfig is another tool that can help enforce consistency in code, and it works in just about every code editor you can imagine.

JSLint is one of the oldest tools that can analyze JavaScript code and tell you about problems. You'll learn how to use JSLint to catch problems from both the JSLint website and command line interface. And, how you can integrate JSLint within WebStorm.

JSHint is yet another tool to help point out issues in JavaScript code. You'll learn how to integrate it with WebStorm.

ESLint is the latest incarnation of tools to analyze JavaScript and tell you about problems. You'll learn how to integrate it with WebStorm.

You'll see how all of these tools can combine to create a workflow to catch problems before they happen, especially when you work with other people.

Fixing common problems, especially with code structure, would still be a hassle even if we have a tool like ESLint to point out the problems. You'l learn how to combine ESLint inspections with WebStorm's code formatting to fix problems at the push of a button.

Share your code from real projects you're working on. Perhaps you have a new perspective or a question, please post a link in the discussion of this lecture to a jsfiddle or repl code sample (or any mechanism online through which you can share code), and I'll provide you with feedback.

Aleks shared his changes to the bubble sort hands on example from the first lecture on meaningful naming.

Share your code from any of the examples in this course. Perhaps you have a new perspective or a question, please post a link in the discussion of this lecture to a jsfiddle or repl code sample (or any mechanism online through which you can share code), and I'll provide you with feedback.