

Are JavaScript Linters the Answer? - WalkerCodeRangr
http://www.walkercoderanger.com/blog/2014/04/are-javascript-linters-the-answer/

======
jeswin
JS has some issues. But the examples in your articles mostly mean that you
need to spend more time understanding the language. It seems as if you were
expecting it to behave like C#.

    
    
        myRide = new Car("BMW");
        letsDrive = myRide.drive;
    
        letsDrive(); // alerts "You are driving a undefined"
    

The 'this' pointer refers to the object on which you wrote the 'dot' to invoke
the function. If you wrote a.b(), then inside b() 'this' will be 'a'. In your
example, you used a function pointer directly without the 'dot' and got
undefined. That is not a bug or a "mine", that's how JS works.

From the last article (why CoffeeScript isn't the answer) in the series:

    
    
      eat food for food in foods when food isn't 'chocolate'
    

> The declaration of what food is occurs in the middle of the line and doesn’t
> even look like a variable declaration. That code could easily be worse if
> "unless eat is undefined" was added to the end, making the whole line
> conditional.

You'd probably have issues with Python too for it's comprehensions. You should
see beyond elementary syntax if you want to make arguments about languages.
These details aren't even a preference; you get used to it in no time.

Summary for people jumping into JS from other languages, buy some good books
because JS is somewhat different. Also, the "minefield" isn't that big a deal
in practice.

~~~
akbar501
> Also, the "minefield" isn't that big a deal in practice.

I completely agree. The vast majority of complaints about JS have to do with
not knowing what the language is designed to do. I previously cursed JS until
I spent the time to read/reread enough JS books to know what it should do. If
I get unexpected behavior now, I know it's an error in my code, or I don't
understand what should happen (thus time for me to read and learn).

As you pointed out, the examples yield the expected behavior.

myRide.drive();

// outputs 'BMW' b/c `this` is pointing to the instance

letsDrive = myRide.drive;

letsDrive();

// model should be undefined b/c myRide.drive is a function that is assigned
to the letsDrive variable. Thus, `this` points to letsDrive, which of course
does not have a `model` property.

To get letsDrive() to output a value other than undefined, we can simply
create a `model` property and assign it a value.

letsDrive.model = 'Mercedes';

letsDrive();

// outputs 'Mercedes' b/c letsDrive now has a model property.

Lastly, the `delayed` method returns an anonymous function which in turn
returns this.model. As JavaScript has function scope, the `this` inside the
anonymous function points to the anonymous function itself. As the anonymous
function does not have an attribute named `model`, undefined is returned (as
expected).

~~~
paultannenbaum
Your example is wrong. You can't attach object properties to a function.

Javascript context is pretty simple. The keyword 'this' by default points at
the object that the method belongs to. When you invoke this function :

myRide.drive();

the myride object owns the drive function, so any keyword 'this' inside of the
drive function will be referring to the myride object.

when you do this:

letsDrive = myRide.drive;

letsdrive is now a function that belongs to the global object (window) since
we did not declare an object for it. So 'this' is reffering to the window
object.To get the output in your example, you would say

window.model = 'Mercedes';

And invoking letsdrive() will now return the expected result

~~~
tlb
Functions are objects, and you can attach properties to them.

    
    
      function foo() {}
      foo.bar = 7;
      console.log(foo.bar); // prints 7

~~~
paultannenbaum
I stand corrected on not being able to attach properties to a function, but
what I said still holds true. The keyword this refers to the object that owns
the method. The original commenter was saying that it was the method itself
that was what this points at.

letsdrive = myRide.drive window.model = 'mercedes'; letsdrive.model = 'bmw';

letsdrive(); // outputs mercedes

------
cheepin
I would love to see a nicer language replace JavaScript as much as the next
guy, but it seems rather unlikely especially given the changes that ECMA has
approved in the past.

I am really hoping that some day, we will be able to do front-end devwork that
isn't just an abstraction of JS/HTML/CSS.

~~~
randomdata
Out of curiosity, what pieces do you believe are missing from your dream of
front-end development work? You can already get a WebGL context from languages
like C or C++ (compiled to asm.js), which should provide all the necessary
building blocks to largely duplicate the front-end development toolkits that
you find in native environments.

I mean you're still hinging on some incarnation of Javascript to act as the
virtual machine, and you need HTML to setup the basic environment, but those
seems like minor implementation details. Nothing that should impact your
creativity in any major way. But perhaps I'm just not thinking big enough?

------
gotofritz
Linting is not THE answer, but it's surely a useful tool that catches a lot of
potential mistakes, and has the nice side effect of enforcing some sort of
house rules.

The problem is with the linters themselves. JSLint is coded by Crockford,
probably the most opinionated sw engineer on earth. It checks what he thinks
is right, and mixes formatting checks with syntax checks.

JSHint is a small improvement, it allows you to switch off rules that
Crockford doesn't even want to talk about, but apart from that it's not a
great step forward. Plus, for no good reason at all they decided to rename
some of the rules from JSLint, and switch some of the flags, so that sometimes
"true" means enforce something, something it means refuse it. It's rather
confusing.

Neither allow you to add your own rules easily.

The new kid on the block is ESLint. It has a pluggable architecture, different
warning levels, and make no assumptions whatsoever. With its open architecture
and access to the syntax tree it should be possible to create a plugin to
check just about anything you care about. It is just coming out of alpha,
their first step is to duplicate JSHint's functionality and then move forward
from there.

It looks very promising.

------
67726e
This is an area I think IntelliJ really shines. The built in JSHint/JSLint
makes developing and finding problems a lot better. It is still a dynamic
language at the end of the day, but it makes itmore bearable.

~~~
camus2
> but it makes itmore bearable.

not when you have a huge codebase and you have to remember what function takes
what kind of argument and returns what kind of result.

People might hate java,but i rarely have to learn any api by heart in java.it
might be more verbose but it's just easier to write on large scale(and to
discover without opening any library doc). Can developpers learn the new
version of express without viewing the source code or having the doc opened on
their second screen?

i thought about the problem, and I like the typescript "header" system for
quick documentation(instead of jsdoc or closure comments ) , maybe there is
something that can be adapted to js here...

then you have ternjs that helps a little but it's far from perfect.

yet yes,linters are just MANDATORY for js development,and fortunatly are
supported by most editors,even vim.

------
cmckeachie
Great article. Love to hear how other devs run their linter of choice during
their workflow.

