- [Instructor] So far, we've been discussing
concepts and terms.
It's time to start cleaning up our code base
and find errors using linting.
In this chapter, we're going to start
by standardizing text editor configurations.
We'll add support for the standard to both our project
and to VS Code.
Once that's in place,
we'll start comparing linters to see the advantages of each.
With an informed decision,
we'll install a linter that should address our needs.
We'll step through how to create
to the linters configuration
then extend an existing shared linter configuration
to save time.
Then, we'll lint the entire code base
and filter the results to be actionable.
Finally, we'll set up VS Code
to clean code and highlight linter errors.
A developers preferred code editor
is a badge of honor, and typically a passionate decision.
With such a variety of options, how can you maintain
coding styles across multiple editors
with the least amount of effort?
The solution is a system called editor config
which has widespread support
throughout coding related programs and systems.
Editor config, whose homepage is editorconfig.org
is a system that defines and maintains
consistent coding styles across editors.
It consists of two parts.
The first, this is a file format
which defines a coding style,
mostly around the use of white space.
The second is a text editor plugin
which reads the file format.
When used it configures the editor
to adhere to the specified coding styles.
There's a number of reasons
why using editor config is advantageous.
As we learned in chapter one,
standardization improves the quality of a code base
by minimizing inconsistencies.
The editor config file format is human readable
and describes its settings clearly.
It's a free and open source industry standard,
which when using open source software is optimal.
Editor config is flexible enough
to support the configuration of multiple private
and public organizations that I've been a part of.
Finally, editor config is available in most text editors,
either natively or as a plugin.
A number of open source projects use editor config
which in itself is a good endorsement.
Node JS, the programming language we're using
is a good start.
jQuery, the venerable cross-platform JavaScript library,
the lodash utility library, the React user interface library
and the webpack module bundler all use editor config.
So, what's an editor config actually look like?
I've included a complete editor config configuration file
which uses almost all of the options
in the solutions directory.
As you can see, it's fairly brief and human readable.
We're going to go through each setting.
So don't worry about reading every line.
If you just want to use editor config
without knowing how it works, skip to the next video.
Editor config files are named .editorconfig.
They use the INI text file format, which is quite forgiving.
All the properties and values are case insensitive
which improves usability.
You don't have to use all the properties at once
if you don't need or want them, which is flexible.
Editor config supports comments,
which start with either a pound sign or a semi-colon.
For example, this is the header from the file
which gives context to other developers
about what this thing is
and where to get more information about it.
The root property, which in our example was set to true
is a special property that should be at the top of the file.
Root indicates that the current file
is the top most editor config file in a project.
This tells the plugin
not to search in the parent directories
for another configuration file, which improves performance.
As such, only set root to be true
in the root directory of the project.
Root takes a Boolean value, so true or false.
Editor config files are broken up into sections
which have a consistent naming convention.
They start with an open square bracket, the file path,
then a closing bracket.
This matches in a given file path using globs
which should be pretty familiar
when I start giving examples.
The asterisk character is a wild card
for any character except the path separators.
For example, a section for asterisk will match all files.
A section for asterisk dot md
will match only markdown files with that extension.
Section names can match with additional patterns
such as a curly brace to match either name.
The double asterisk matches any characters,
including the path.
Put them together like this section name
and you'll recursively match all JavaScript files
within the lib, source and test directories
Within each section are pairs of properties and values.
The indentation properties start with the eternal question,
what indent style should be used, tabs or spaces?
Then, what size of the columns should the indent be?
For spaces, this is the number of single-spaced characters.
The value is an integer or tab if the indent style is tab.
If you're using tabs
then you need to specify the tab width,
which is the number of columns for each tabstop.
This is only useful when using tab
and it defaults to the indent size
so there's a good possibility you won't need it.
Here's an example of indentation properties.
This one uses spaces, not tabs and two spaces per indent.
A related property is end of line,
which is the line ending format.
There are three potential values.
The first is LF for line feed,
which is used for Unix and Linux.
Next is CRLF for carriage return and line feed
which is used for DOS and Windows.
The final is CR just carriage return
which is sometimes used by Mac.
A good choice is LF for line feed
for compatibility with other utilities.
The file character encoding using the charset property
is also important.
Latin1 is limited and will corrupt non-Latin characters
including mission-critical emojis.
Utf8 is the most common in coding
and I and other projects recommend it.
There's also utf8be for big-endian byte order
and utf16le for little-endian byte order
if you need an extended character set.
Most developers will be fine with a charset
set to utf8.
The trim of trailing white space property specifies
whether white space is allowed at the end of lines.
This is definitely a code style,
but it does affect maintainability.
Nobody likes navigating to the end of the line
only you find some phantom space that needs to be trimmed.
This is a Boolean property, so true or false,
therefore setting trim trailing white space to true
will lead to a more consistent and clean code base.
The final property is insert final new line
which ensures files end with a new line when saving.
This is important because in Unix text files
every line must end with a new line.
If a file isn't empty and doesn't end with a new line
it's not considered to be a text file.
This can cause bugs and other weirdness in other systems.
It's a Boolean property as well
so as an example, insert final new line can be set to true.
That may have been more than you ever wanted to know
about editor config,
but I've found that knowing how something works
is better than just blindly using it.
Also you'll be in a much better position
to optimize the configuration meet your needs.
Let's install editor config support into VS Code
and add the configuration file to our project.