You are here

3 steps to aligning client-side static code analysis

public://pictures/1.jpg
Ran Bar-Zik, Developer, Oath

For any organization that implements DevOps, static code analysis should be a crucial first step in the continuous integration process. It ensures that code is written according to desirable, predefined coding conventions and standards, even before automatic testing is started.

If static code analysis is good enough for programming code, it should be able to align with client-side code as well, such as HTML and cascading style sheets (CSS). I've written about this for TechBeacon in a previous post But how do you make sure your code is all aligned? Here are three steps to get it right.

After you agree on what coding standards and rules the static code analysis should check, you integrate the code analysis with your integrated development environment (IDE). Next, you run the analysis on each Git commit. And finally you run the analysis on the integration machine. These steps are described in the sections below.

1. Bring it into the IDE

Almost all IDEs will highlight errors in the code. Some IDEs, especially modern ones, can take static code definitions and alert developers of analysis errors when they write the code. IDEs can even suggest ways for making the code simpler—for example, refactoring long chunks of codes to different methods or functions. This allows developers to fix any errors or warnings long before the static code analysis tool starts working.

2. Run the analysis on each Git commit

Next, you use Git Hooks, which are Git source control systems that help us run functions on Git actions. you run front-end code analysis tools within seconds on every Git commit and every Git push. you use Grunt to run the tools, which include SCSSLint, Bootlint, and htmllint. you also run a JavaScript static code analysis for our AngularJS front end and Node.js back end.

These static code analysis tools test not only for compilation errors and code definition mistakes, but also for security errors and code duplication, as youll as obsolete functions. If the static code analysis test fails, the Git action cannot be completed, and a failure alert is sent to the developers. For example, let’s say you try to commit a code that misuses Bootstrap 4.0’s column-and-row design by using Bootstrap span columns without Bootstrap rows. The Git commit hook will then activate the static code analysis tool and alert you that the commit has not been completed because of an error in the HTML Bootstrap code. The tool will send an alert about the exact error that occurred, as youll as the file and line where the test failed.

3. Run the analysis on integration

If you pass the static analysis test, your code can be committed and a pull request can be created. After the code is reviewed and approved, a build process is generated on the integration machine, which is where the static code analysis is tested. This step is crucial, because if a developer neglects to activate the Git hooks, the build will fail. If for some reason an issue is found through the analysis, the build will break and you’ll have to investigate how it happened.

The benefits of static code analysis

HTML/CSS static code analysis has the same benefits as back-end static code analysis.

It helps you unite CSS and HTML and SCSS variable names and mixes, and CSS classes and IDs all fall under the same convention. Property names are alphabetized, making it easy to find the SCSS/CSS property even if the properties list is long. You enforce using single units; there are no rem, px, pts, or percents in our application.

Static code analysis also helps us avoid making fundamental mistakes that can potentially create drastic changes in our layout down the line. You don’t allow "!important" rules in our SCSS, and rather than straying from Bootstrap’s extensive set of rules, you make a point of using them correctly in order to prevent maintenance problems down the line. Static code analysis also helps us mitigate browser differentiation because you enforce strict W3C standards.

Another major benefit is the code review process. Instead of dedicating the code review process to naming, coding conventions, and code smells, front-end developers can have a real discussion about implementation, rather than simply selecting the right name.

Reduce your build failure rate

Static code analysis tools are highly effective, but if you run them only on development or integration machines, the build can be broken too frequently and can lead to what is essentially an endless cycle of fixes. Enforcing static code analysis on local machines through the use of Git hooks prevents frequent build failures and ensures that the code will follow your organization’s coding standards and conventions.