Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Client-side static code analysis: It's not just for code anymore

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

Software engineers have long used static code analysis, also called linting, to improve software quality when programming in a variety of programming languages, from C’s ECLAIR to Java’s Checkstyle. But it can also help development teams mitigate the hardships they face when too many cooks are in the kitchen — especially when you're writing for a single application over the span of a few years.

For example, if one developer names the function of a class or method one way, while another uses a different name, it can be difficult to identify exact functions within a given script. Even the little details, such as inconsistent indentation and spacing, can make your code hard to read. Imagine how frustrating it would be to read a book where indentation and spacing of the text constantly changed. By using static code analysis, you can help developers find errors before they compile or run the code and alert them about any other issues, such as a lack of inline documentation, bad coding standards, security issues, performance issues, and so on. 

Why should the benefits of static code analysis only be used on back-end code and front-end scripts? Let me show you some tools and methods for analyzing your HTML, CSS, and SCSS as well.

Classic uses of static code analysis

Static code analysis features differ from tool to tool, and from language to language, but most fulfill the following functions:

  • Ensuring code uniformity. When a team uses static code, the code looks consistent. For example, developers name the classes, methods, and properties in agreement with the selected coding convention, either with or without capital letters and underscores. They name these according to the standards that the team has developed. Uniformity is essential when a group of people write code. Having it all look the same ensures that, after several years, other developers will be able to understand the code and how it’s supposed to function.
  • Enforcement of code documentation. Inline documentation is very important for new developers, who are trying to integrate with a team. Static code analysis can enforce documentation according to standards (mostly DOXYGEN). Certain static code analysis tools insist on correct wording and phrasing. When every class, method, and property is documented properly, it is much easier for a new developer on the team to start digging in.
  • Identification of security issues. Good static analysis tools can alert you about a variety of security issues. For example, it can alert you about escaping front-end output, and validation and sanitization of input from the front end, to prevent cross-site scripting (XSS)it can help you enforce token usage to avoid cross-site request forging (CSRF); and it can alert you ab out unsanitized input to the database to help you avoid SQL injection attacks.
  • Application to client-side JavaScript. Although static code analysis is common practice in back-end coding, you can use it for client-side analysis as well. Experienced developers who work in JavaScript frameworks such as AngularJS use JavaScript static code analysis utilities such as ESLint and JSHint.

Taking static code analysis beyond programming

Static code analysis needn't be limited to your programming code. You can enforce coding standards on all components of your front end, such as in cascading style sheets (CSS) or your CSS scripting code (SCSS) or Less files that you use to generate CSS files. Those scripting languages are very common in large projects and can help you maintain large CSS files. My team uses SCSSLint for SCSS file static analysis. We use variables for colors and only use specific units when defining element sizes in our SCSS. Because we have 10 developers writing SCSS for the same product, this is the only way we can ensure quality code.

In my organization,we use Bootstrap 4 to perform static code analysis on HTML files, and we use Bootlint to ensure that each client-side developer uses Bootstrap properly. This prevents developers from accidentally misusing their container>row>column setups or from using HTML tags without the proper attributes.

You can choose from a variety of tools that that will run a static analysis on HTML, even if you don’t use Bootstrap. For example, the web application scanning tool Grabber detects vulnerabilities such as cross-site scripting. Using it will help you enforce valid HTML and CSS, as well as achieve all of the benefits that come with standard programming language static code analysis.

Your own personal code reviewer

Static code analysis is like having another person review your code. Most developers won’t check code in until it’s been reviewed by a colleague, and static code analysis tools can be the reviewer who is always available, ready, and waiting for you. It's always alert, keeping a look-out at all times for potential issues. Yes, static code analysis can be overzealous on occasion and produce false positives, but most tools have configuration options that let you fine-tune the way they work.

Today, you can apply static code analysis tools to just about every language and script, whether compiled or interpreted. With almost zero effort, you can ensure that the code that reaches your deployment pipeline, whether client-side or server-side, conforms to coding and style guidelines, and more importantly, is clean and free of issues that your human reviewers could miss. Don't just use it on the back-end.

Image credit: Flickr

Keep learning

Read more articles about: App Dev & TestingApp Dev