Coding Standards Make the World Go Around

Programming with ESLint

Over the course of my Computer Science career, I haven’t been adhering to any one single stype of coding. In fact, until only recently, I’ve just been picking and choosing bits form different styles where I thought, “Hey, that’s pretty good”. For example, a standard for writing Java methods is to place the initial curly brace a space after the parameters. But in C programming, functions are written with the initial curly brace on a new line after the parameters. These are small changes, but when you are programming for numerous classes, these things grow on you, and the C coding standard was doing just that. With C being the most recent language that had changed this standard for me and, admittedly, being sick of Java, I have been using the C standard for all of my programming needs from writing PHP to the early parts of learning JavaScript.

Then I installed ESLint.

Much like the sterotypical, tyranical english teacher brandishing a yard stick, the ESLint utility will leave you covered in red marks if you do not carefully adhere to its standard. And it is a very strict standard. So strict that code will run perfectly, look at the very least legible, but still have the dreaded red lines lining your precious work. But these are good things. Old habits die hard as they say and ESLint, or any linting utility really, will make it far easier for them to go six feet under. Every mistake you make you will correct, and the things you weren’t aware were even mistakes will be learned through simply going about your programming routine. So while ESLint does slow down my WOD times with needing to correct various syntax and grammar, it is for good reason.

What is the Point of Code Standards?

What is the point of any standard really? The answer usually is uniformity. But what does uniformity do?

To sum up the answer to that question; uniformity, at least in the world of Computer Engineering, gives programmers the basis to how to code thier programs. Consistency is a key element in any project situation which involves multiple developers. By upholding and adhering to a standard, one can produce readible, eloquent code that can be easily read by those who also know that standard. This, in turn, removes the middle man of having to explain to someone your code. And, of course, this means more focus at the programming at hand.

Lets take small look at what ESLint enforces for example.

function fib(amt) {
  let max = amt - 2;
  const result = [];
  let second = 0;
  let first = 1;
  let sum = 0;
  result.push(second, first);
  for (let i = 0; i < max; i += 1) {
    sum = second + first;
    result.push(sum);
    second = first;
    first = sum;
  }

  return result;
}

The above code is the initial function that I had coded before any ESLint edit and the block after is after I had edited. Can you see the difference?

function fib(amt) {
  const max = amt - 2;
  const result = [];
  let second = 0;
  let first = 1;
  let sum = 0;
  result.push(second, first);
  for (let i = 0; i < max; i += 1) {
    sum = second + first;
    result.push(sum);
    second = first;
    first = sum;
  }

  return result;
}

Now these two functions had worked as intended and are viable implementations of generating a fibbonacci sequence. But ESLint won’t allow the first implementation. And that is due to the declaration of max as a let rather than a const. ESLint has detected that max is not changed anywhere in the function, and thus should be declared as a const. After thinking about it, this does make a lot of sense. Declaration of a variable by using const or let can communicate a crucial piece of information that can make or break a program. Max, in this context, is the “true” amount of fibbonacci numbers to compute, as the result will be populated with the first two numbers. Thus, any change to max (when declared as let) would interfere with the amount of numbers the function will compute.

While a modificaton of max would not cause devestating problems in this case, imagine a project with thousands of lines of code with a team of at least ten. In a standardless programming world (a nightmare), a small little thing such as having a let instead of a const can spur some catastrophic repercussions through miscommunication.

So while, yes, standards do very little in way of helping the lone programmer; standards are essential to having good work ethic with collaborators and teams.