What does Linting and Beautifying(Prettifying) the front end code mean???
L int or Linter is a tool that that analyzes source code to flag programming errors, bugs, stylistic errors and suspicious constructs.
The term “ lint ” was derived from the name of the undesirable bits of fiber and fluff found in sheep’s wool.
Lint like tools are especially useful for interpreted languages like JavaScript and Python. Because such language lack a compiling phase that displays a list of errors prior to execution, the tools can also be used as simple debuggers for common errors.
TOOLS FOR JAVASCRIPT(JS) LINTING —
Out of these choices for linting, ESLint is currently the widely used and is very easily configurable. JSLint is strict and not configurable, whereas JSHint lack the extension mechanism. JSCS is a good choice if you only want to check coding style but ESLint does that and it checks your code for bugs and other problems as well.
ESLint is also the obvious choice if you want to use ES6(ES2015). Of all the tools mentioned, it has the widest support for ES6 features.
JSHint is strong second choice. If you don’t need the advanced features of ESLint, JSHint catches a good number of issues once properly configured.
JSCS with its huge number of available rules, is a top pick if you don’t need anything other than coding style checks(indentation,braces etc.).
I am hesitant to recommend JSLint at all. The other tools do the same things, but don’t force any specific rules on the user. The only exception here is if you happen to agree with all the rules it enforces, in which case it might well be worth looking into.
A linting tool is a good step towards catching problems, but it only sees as many errors as its rules permit. For a more full proof automated bug-catcher, I recommend using unit tests. Code reviews can also be useful for this purpose.
CODING STYLE A.K.A. PRETTIFYING THE CODE —
Coding style is how your code looks.
Coding style is extremely personal and everyone has their own preferred style. This is because of the way one learned to code. If you used an I ntegrated D evelopment E nvironment( IDE ) like Sublime Text, Web Storm, Visual Studio etc. to learn coding your style probably matches the one enforced by the editor. If you learned using a plain editor, you style likely evolved from what you thought was more readable.
It is very important to notice that coding style changes from language to language. The decisions that you made in JavaScript might not carry over to your CSS. For instance, you might decide JavaScript strings should use double quotes while CSS strings should use single quotes. This isn’t uncommon as we tend to context switch when we switch back and forth between languages.
Coding style is made up of numerous small decisions based on the language -
- How and when to use comments
- Tabs and spaces for indentation
- Appropriate use of white space
- Proper naming of variables and functions
- Code grouping and organization
- Patterns to be used
- Patterns to be avoided
and many many more ……
CONCLUSION (It’s Very Personal )
The personal nature of coding style and linting is a challenge in a team atmosphere. Often, seeking to avoid lengthy arguments, teams defer creating style guide or use common linting guidelines under the guise of not wanting to “discourage innovation and expression”.
