Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.2 Code Style Enforcing

Along with linting, another essential task is code style enforcement. When working with a team of developers, differing code style can cause disagreements and inconsistencies that make the code difficult to maintain. Enforcing a code style eliminates these issues, so in this lesson I'll show you how to install and configure the JSCS task.

2.2 Code Style Enforcing

Hi, folks. In this lesson, we're going to take a look at how we can enforce a particular coding style for our projects. So first of all, let's get the gulp-jscs plugin installed. And as before, we can also install a better reporter. Having a defined coding style, preferably explicitly specified in a style guide, is essential for large projects involving numerous developers. If a code style is not enforced, developers will mostly end up writing code according to their own preferences, and over time the code will become less and less consistent which can affect maintainability. There are a number of different tools available for checking code style. One such tool is JSCS, which stands for JavaScript Code Style. JSCS has recently merged with ESLint, another popular style checker. But this just means that there won't be any new versions of JSCS. The current version is still available and is still very, very popular. So once that's installed, we can add a new JavaScript file to the Gulp_tasks directory. And let's just call this JSCS. So first of all we need to require in the modules that we need. So now we can add the main body of the task. And as before we want to set the exports property of this module. And just like with the JSHint tasks that we look at in the last lesson, first of all, we're going to need to collect some source files to pass to the JSCS module. And as before we're saying that we want to collect all of the JavaScript files in any directory in the src directory. So now we can pipe these to jscs. And once jscs is finished with the files, we can then pipe them to the reporter. So far, this is very similar to the JSHint task that we created in the last lesson. It's just using JSCS instead of JSHint. JSCS also requires a configuration file. So we need to add this next. We need to create a .JSCSRC file and inside we can add a JSON object containing the configuration that we want to use. So on Windows, once again, we need to add this as a .jscsrc file that doesn't have an extension. And we can just do that by creating a text file and then renaming it to have a dot at the start and to remove the txt from the end. So JSCS is highly configurable and has many, many style rules that we can enable or disable. To avoid having to create a huge configuration each time you want to use JSCS, we can use one of a number of different presets that ship with the tool. There's an Airbnb preset, a jQuery one, Google, Grunt as well as a few others. As we went with the strictest rules in the JSHint configuration, let's go with the Crockford preset for JSCS So let's also add a new test file. We can also add this to the src.js directory. And let's call this one style_test. And inside let's just add some code that is definitely not going to meet the rules defined in the Crockford presets. So that should definitely throw some JSCS errors. So at this point we should be able to run our new JSCS task. But before we do that, we just need to tell JSCS where our configuration file is. And we can add a configuration object to the JSCS module and we just pass that in as an argument. And the property that we want to set is the config path property. We just need to point that to the .JSCSRC file. So now let's run our new task. So it's found quite a few code style errors and some of those are in the jQuery file. So we can see straight away that we're going to want to tell JSCS to ignore any third party code just like we did with JSHint. With JSCS, however, we exclude files and folders using the configuration file. So let's just tell it to ignore any files in the vendor folder. So now let's run the task again. So this time it's only found seven style errors and they're all in the style test file that we added earlier in the lesson. At the start of the lesson we installed the stylish reporter so we also need to switch to using that. Let's do that quickly. And it looks like there's a typo. We just need to add a comma at the top here. So this time, instead of using the default reporter that is a property of the JSCS module, we can just use the reporter that we required at the start of the lesson, the gulp JSCS stylish reporter. Let's run that again. This time, the results are a bit easier to read and it just looks generally a bit nicer. JSCS has another very powerful feature. When it finds errors in the code it can sometimes fix them automatically. So let's see this in action. We just need to add another property to the configuration object that we passed to the JSCS module. So the property that we set this time is called fix, and we just set the value of that to true. So JSCS will now generate a new file for us, which fixes the issues that it's found, and we just need to tell gulp to save this file. And we can do that by piping the updated file to the gulp.dest method from the reporter. JSCS will generate a new file containing the code that is fixed, so we just need to tell Gulp where to save it. And we do that by piping the updated file to the gulp.dest method from the reporter. The new file will have the same file name as the input file. We just need to tell it the path that we'd like to save it. So we'll just put it back in the js folder. So let's run the task again. And it still found a couple of issues. But let's take a look at the style test file now. So it's fixed some of the issues for us, mostly by adding spaces in between various things. So that's fine. But it looks like the vendor directory is being copied as well. We just need to make a slight change to the dest arguments here. Let's just try updating the path once again. And let's get rid of these folders again. Okay great, so this time it's not copying over and duplicating our folders. And that's what we want. So we've added two tasks so far, jscs and jshint. They're both pretty similar and we'll probably always want to run them both on the same set of files. So let's create a new lint task that runs both the JSHint and JSCS tasks for us. Because this is gonna be an alias rather than a proper task, it's just gonna run other tasks, we can use the nested array format. Now we should be able to run gulp lint and have it run both of these tasks for us. Perfect. So in this lesson we saw how to install and configure the gulp-jscs plugin in order to enforce a code style. In the next lesson we're going to move on to the second section of the course to focus on some more build related tasks starting with compiling SASS to CSS ready for deployment. Thanks for watching.

Back to the top