== Why is this an issue?

The fact that JavaScript is not a strongly typed language allows developers a lot of freedom, but that freedom can be dangerous if you go too far with it. 


Specifically, it is syntactically acceptable to invoke any expression as though its value were a function. But a ``++TypeError++`` may be raised if you do.


=== Noncompliant code example

[source,javascript]
----
foo = 1;
foo();   // Noncompliant; TypeError

foo = undefined;
foo();  // Noncompliant; TypeError
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

This expression might have a value which cannot be called; it might not be a function.


'''
== Comments And Links
(visible only on this page)

=== is duplicated by: S2872

=== is related to: S5756

=== on 27 Apr 2015, 13:46:34 Linda Martin wrote:
\[~ann.campbell.2 ]assigned for completion



=== on 28 Apr 2015, 14:27:59 Ann Campbell wrote:
Double-check my changes [~linda.martin].


Also, should we add a compliant solution showing the addition of an undefined-check?. E.G.

----
if (foo !== undefined) {
  foo():
  //...
----
?

=== on 29 Apr 2015, 12:53:44 Ann Campbell wrote:
Updated with larger scope per discussion on RSPEC-2872



=== on 2 Jun 2015, 13:33:20 Linda Martin wrote:
\[~ann.campbell.2] I don't think a "Compliant" section is needed.

I slightly updated one message.

=== on 16 Jan 2020, 14:05:14 Elena Vilchik wrote:
Deprecating rule.

We realized that this rule was never behaving very well, most of the issues that we could observe were false positive. Even with the current migration improvement, we will not have the tools to improve the results to a state where it's worth the migration effort, we therefore decided to deprecate it.

https://github.com/SonarSource/SonarJS/issues/1810

=== on 11 Mar 2020, 11:09:24 Nicolas Harraudeau wrote:
Moving the python implementation to a separate rule (RSPEC-5756) as this one is deprecated.

endif::env-github,rspecator-view[]
