-4

I've searched SO for a comprehensive answer for this question, but I can't seem to find any, so I would appreciate a comprehensive answer on the benefits of linting applications in Typescript and Javascript, or a link for an answer like that.

I've been linting applications since I started writing Typescript code and linting was common sense for me, there's a good feeling attached to writing clean code. However I've stumbled on a Typescript code that is riddled with linting errors and my code editor has errors every couple of lines. Obviously this doesn't feel good but I was wondering why exactly is it recommended to lint JS/TS applications before shipping them, especially since the applications I currently have to work on don't seem to have been ever checked for TS linting errors, and they work without any problems? Is it only because it's clean or does it have any performance or other benefits?

amouda
  • 367
  • 4
  • 19
  • 2
    The existence of poor code doesn't mean that more should be created. This sounds like it's related to the "broken window theory". – Carcigenicate Jan 24 '19 at 12:26
  • 1
    Please visit the [help], take the [tour] to see what and [ask]. Do some research, search for related topics on SO; This question is off topic and in my opinion slightly strange. – mplungjan Jan 24 '19 at 12:27
  • 1
    How is it strange? I'm just asking the benefits of linting other than just writing "clean code". – amouda Jan 24 '19 at 12:29
  • I certainly prefer to read code that is indented properly and does not have huge chance of failing due to spelling or indentation errors – mplungjan Jan 24 '19 at 12:30
  • 3
    Linters point out *potentially* problematic code. *Potentially* problematic doesn't means it's *actually* problematic in that specific case. But avoiding problematic code in general surely is safer. – deceze Jan 24 '19 at 12:30
  • _"Is it only because it's clean or does it have any performance or other benefits?"_. Response 1. – Paleo Jan 24 '19 at 12:38
  • The computer doesn't care how pretty the code looks. Linting is meant to make the code easier to read and work with to other humans. – JJJ Jan 24 '19 at 12:40
  • Note that linters can also auto-fix cosmetic issues. If you're using legacy code (read, anything from before introducing the current linting rules), you may come across a non-conforming file that has loads of issues. Running the auto-fix option can remedy most of the trivial issues. Assuming the code currently works, it's fine to leave it as-is and address the errors at a later point, although fixing them is still preferable. You might even find a real bug in existing code (I've had that happen). – VLAZ Jan 24 '19 at 12:43
  • 1
    [What is "Linting"?](https://stackoverflow.com/questions/8503559/what-is-linting) provides answers on "what" is linting, but it doesn't provide any answers about "why" you should lint, say, to convince your colleague to actually lint instead of just writing whatever code he wishes instead of "clean code" for example. – amouda Jan 24 '19 at 13:37
  • 2
    @amouda surely the "what" indicates to the "why", no? So the "what" might be: '*Linting is the process of running a program that will analyse code for potential errors.*' so the "why" would be '*To find potential errors that were missed by the developers.*' – Script47 Jan 24 '19 at 15:01
  • @Script47 it is right, "what" implies "why". – Mosè Raguzzini Jan 24 '19 at 16:24
  • since when some pointing and implying is the same thing as an `comprehensive answer`..? – Aprillion Jan 25 '19 at 11:48

2 Answers2

3

Linters exist to point out common potentially problematic code patterns, based on many years of experience of the community overall and the creators of the linter in particular. Most linters are also extensible with custom rules, should you need to enforce custom conventions in your specific project for one reason or another.

Potentially problematic doesn't mean that code will actually produce errors in that specific situation. But avoiding such potential problems in favour of using known better patterns is surely better. Linters are typically ultra conservative, which doesn't mean less conservative code can't work. But don't complain nobody told you, should you venture into such territory and produce bugs.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • 3
    Probably worth noting - fixing existing code should be done with care. For example, the code uses `myVar == null` and the linter rules require `===` - adding a single equals does change the meaning of the code and can lead to errors where there weren't before. You might find a big chunk of code that doesn't conform and changing all of it could be labour intensive for one reason or another. But that doesn't mean you *shouldn't* address the issues. You could leave them for later but also loosen up the linter rules or even turn them off for a section of code, if really needed. – VLAZ Jan 24 '19 at 12:48
2

I like the rationale from https://www.jslint.com/help.html:

If a feature is sometimes useful and sometimes dangerous and if there is a better option then always use the better option.

...

When C was a young programming language, there were several common programming errors that were not caught by the primitive compilers, so an accessory program called lint was developed that would scan a source file, looking for problems.

As the language matured, the ... compilers got better at issuing warnings. lint is no longer needed.

JavaScript is a young-for-its-age language. It was originally intended to do small tasks in webpages ... Many of the features that were intended to make the language easy to use are troublesome when projects become complicated. A lint for JavaScript is needed ...

IMHO the next generation of linters (e.g. eslint)took this core philosophy, but replaced some of the strong opinions with configurable options to reach wider audience. Plugins for frameworks were added. Options were added to address code formatting, not just potentially dangerous features. People disagreed on some options and opinionated formatters found their niche (e.g. prettier).

Typescript seemed to implement the most important code-quality rules as part of the compiler core, while the more controversial rules are left over for external linters (e.g. tslint) for teams that decide to enforce consistent code style (to improve readability, ...).

Not sure how much consistent code style improves code quality, but I'm reasonably convinced it doesn't decrease the quality and can have potentially huge benefits (if I find trustworthy research on the topic, I will add to this answer).

Community
  • 1
  • 1
Aprillion
  • 21,510
  • 5
  • 55
  • 89