How Linting improved my coding skills

Or how Wikipedia puts it:

In computer programming, lint was the name originally given to a particular program that flagged some suspicious and non-portable constructs (likely to be bugs) in C language source code. The term is now applied generically to tools that flag suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage.

Which might be a slightly better explanation.

What does actually happen?

So, linting applies a set of rules to your code and tells you where you should improve your it, not necessarily because you did something completely wrong, but because your code might cause some unwanted side effects you've not been aware of. E.g., a few years ago, I did this very frequently:

			
				for (var i = 0; i < elements.length; i++) {
					elements[i].addEventListener('click', function(e) {
						// do smth.
					});
				}
			
		

If you throw this into a tool like JSLint, it will tell you something like

Don't make functions within a loop

Which is absolutely right. This code would work perfectly fine, but it is a waste of time and memory to declare the function in each iteration, plus at least when you come back here for debugging or refactoring, you might wish you would have made this a propperly named function like "doSomethingOnClick()" instead of an anonymous one, for reasons of clarity and comprehensibility. So this might bee a much better approach:

			
				function doSomethingOnClick(e) {
					// do smth.
				}

				for (var i = 0; i < elements.length; i++) {
					elements[i].addEventListener('click', doSomethingOnClick);
				}
			
		

(Sidenote: "doSomethingOnClick" is actually _not_ a good name for a function, it just serves as an example here ;-))

So, linting is a good thing

That is actually pretty great for a cuple of reasons. You may avoid common pitfalls, as well as your code will become a lot more clear and consistent. This is espacially great if you apply linting project- or company-wide, because your whole codebase will become much more consistent. This might be the first step to a code styleguide.

Back in the days, I used to copy my code, paste it into JSLint and then back into my code editor. Nowadys you can easily automate this to put it into a build-process with tools like grunt-contrib-jshint, gulp-jshint, etc. I would even recommend to integrate a linter into you IDE or texteditor of choice. There are linting pulgins for almost every editor and I really like to see potential errors right after I typed them.

There is more

During the discussion I mentioned earlier, I started thinking why I started linting my code and what I actually achieved with it. And I realised a benefit that did not seem that obvious at a first glance, but really made sense once I thought about it.

I really started to get a much better understanding of the language itself after dealing with the error messages the linter gave me. To give an example: I still consider my self a, well, let's say not-so-much-ninja-rockstar when it comes to css. So, when I added a css-linter to my toolchain, my css files pretty much lit up like a christmas tree. One error I got pretty often was something like

Selector should have depth of applicability no greater than 3, but was 5

on a code block like this:

			
				.topbar .navigation .ul .li a {
					// some styles
				}
			
		

I never heard about "depth of applicability" and for all I knew, being explicit about my selectors was a good thing. So I started digging and it turned out that my very deep nested selectors had a big disadvantage that my project was already suffering from. The HTML markup was so tight coupled to my css, that I started to write additional rules for elements that looked similar, but had a different markup. There is an article on SMACSS that explains this problem very well.

So, by trying to get this error message out of my console, I not only cleaned up my css code, but actually started to get a better understanding of how css works and the place it should take inside my development stack.

What it comes down to

I think one should keep in mind that the rules a linter applies to your code are not the word of god and there might always be cases where what you've written is actually better than what the linter wants you to write. And that's perfectly fine (as you always have the option of modifying the rules to fit your needs). 

If you want to learn how something works, you have to use it until you fail, because then you're able to ask the right questions. And linting made me asked questions I never really thought about before.