On writing JavaScript well.

The aesthetics of code.
4.0 (5 ratings)
Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
899 students enrolled
25% off
Take This Course
  • Lectures 81
  • Length 6.5 hours
  • Skill Level All Levels
  • Languages English
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works


Find online courses made by experts from around the world.


Take your courses with you and learn anywhere, anytime.


Learn and practice real-world skills and achieve your goals.

About This Course

Published 1/2015 English

Course Description

It's one thing to create code, it's another to create code that's aesthetically pleasing. And pleasing not just in visual appreciation but also the how the design of the code contributes toward the purpose of creating value for users. With thoughtful consideration, it's possible to decompose the notion of beauty, or good versus bad code, into a set of characteristics that can be used to evaluate alternative styles of code. Code itself is like art, it's subjective. With the right context and a mutual appreciation of consistency, you can create beautiful code.

Words can't describe what I can show, watch the free introduction (below) to understand more about what you'll take away from this course.

What are the requirements?

  • This course assumes you have a basic understanding of JavaScript to the point that you can read and follow along with code examples.

What am I going to get from this course?

  • Identify and apply characteristics that lead to consistent, aesthetically pleasing code. Code that's a joy to be responsible for.
  • Learn trade offs and how to come to a consensus as a team about how to approach consistency.
  • You'll learn to improve the code you write yourself, and improve existing code, in a productive manner.
  • You'll start to see the impact of rewriting or refactoring code and how it can pay huge dividends without much effort.
  • Learn about tools that take the pain out of writing code well, so you can focus on what the code accomplishes.

Who is the target audience?

  • If you're interested in not just writing code, but writing code well, this course is for you.

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.


Section 1: Introduction

Which code sample do you prefer, A or B? What would you prefer to maintain, support, change, read? This is a sample of some of the tradeoffs we'll consider throughout this course, and the format of that discussion.

To follow along, check out the corresponding jsfiddle used in this lecture http://jsfiddle.net/Lsehtkw2/


Aesthetics are subjective, this lecture discusses the essence of how aesthetics plays into code that's a pleasure to be responsible for.


We may never agree on tabs or spaces, let alone many aspects of creating a healthy code base, but consistency is something we all agree upon and can strive for.


This lecture covers the organization of the course and what to expect.

Getting access to code used in the videos throughout the course
Section 2: Naming is one of the best investments

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.

Section 3: Consistency in the structure of code

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.

Section 4: The role comments play in code.

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.

My thoughts about comments in the hands on example
Section 5: Tools that can take some of the pain out of writing JavaScript well
What role can tools play in all of this?

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.

Hands On - try these tools out
Section 6: The impact of function composition
Functions matter too!
Some background on the code example we'll use throughout this section.
Size matters
Applying Command Query Separation (CQS)
Returning early
Not returning early?
Explicit return statements with intermediate variables
Declare variables next to their first use
The compose method refactoring
Parameter overload!
Hands On
Section 7: Further areas of exploration
What next?
Automated testing helps you write code well
My first automated test
Functional programming with JavaScript
Object Oriented Programming principles
Asynchronous JavaScript and the callback nightmare
Future versions of JavaScript and the lambda
Section 8: Share some code and get some feedback

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.

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Wes Higbee, Expert in innovative software development

I'm passionate about helping organizations delight customers.

I've had decades of experience developing software and working with teams to improve how software is developed. My experience spans everything from the conception of an idea, through implementation and ongoing support.

I've been interviewed on The Businessology Show and Art of Value about how important value is in software development. I speak extensively both online and offline about software and business. I routinely write about topics of interest including articles featured in MSDN Magazine, InfoQ, VeraSage and JetBrain's TeamCity blog. I've authored several courses on both Pluralsight and Udemy.

I love creating courses to distill and share knowledge with people just like you, that have an unquenchable thirst for learning and improvement.

Ready to start learning?
Take This Course