== Why is this an issue?

Reading a non-existent property on an object always returns ``++undefined++``. Doing so is usually an error; either in the name of the property or the type of the variable being accessed.


If an attempt is made to access properties of a primitive, the primitive is automatically encased in a primitive-wrapper object for the operation. But being "promoted" to an object doesn't mean that the primitive will actually have properties to access. The wrapper object still won't have the non-existent property and ``++undefined++`` will be returned instead. 


This rule raises an issue when an attempt is made to access properties of a primitive. Thus this rule should only be activated when you don't use monkey patching for standard objects, like ``++Number++``, ``++Boolean++`` and ``++String++``. 


=== Noncompliant code example

[source,javascript]
----
x = 42;
y = x.length;   // Noncompliant, Number type doesn't have "length" property
----


=== Exceptions

The Ember framework introduces a few extensions to ``++String++``. Since it is a widely used package, the following ``++String++`` properties will not trigger this rule even though they are not built-in:

* ``++camelize++``
* ``++capitalize++``
* ``++classify++``
* ``++dasherize++``
* ``++decamelize++``
* ``++fmt++``
* ``++loc++``
* ``++underscore++``
* ``++w++``


ifdef::env-github,rspecator-view[]
'''
== Comments And Links
(visible only on this page)

=== on 1 Nov 2019, 17:34:52 Elena Vilchik wrote:
See \https://github.com/SonarSource/SonarJS/issues/1698

=== on 21 Oct 2020, 16:44:43 Guillaume Dequenne wrote:
Dropping this rule as it has low value. See:


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


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

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