IDENTIFICATION OF JAVASCRIPT FUNCTIONCONSTRUCTORS USING STATIC SOURCE CODE ANALYSISShahriar Rostami DovomA thesisinThe DepartmentofComputer SciencePresented in Partial Fulfillment of the RequirementsFor the Degree of Master of Computer ScienceConcordia UniversityMontre´al, Que´bec, CanadaAugust 2016c© Shahriar Rostami Dovom, 2016Concordia UniversitySchool of Graduate StudiesThis is to certify that the thesis preparedBy: Shahriar Rostami DovomEntitled: Identiﬁcation of JavaScript Function Constructors Using StaticSource Code Analysisand submitted in partial fulﬁllment of the requirements for the degree ofMaster of Computer Sciencecomplies with the regulations of this University and meets the accepted standards with respect tooriginality and quality.Signed by the ﬁnal examining commitee:Lata Narayanan ChairJoey Paquet ExaminerWeiyi Shang ExaminerNikolaos Tsantalis SupervisorApprovedChair of Department or Graduate Program Director20Amir Asif, PhD, PEng, DeanFaculty of Engineering and Computer ScienceAbstractIdentiﬁcation of JavaScript Function Constructors Using Static Source CodeAnalysisShahriar Rostami DovomSoftware maintenance and comprehension constitute a considerable portion of the required eﬀort forsoftware development, and thus, myriad number of studies have proposed approaches for improvingmaintainability of software systems. However, the majority of these studies have examined softwaresystems written in traditional programming languages, such as Java and C++. While the ubiquityof web has resulted to JavaScript to be extensively adopted by developers, studies that investigatemaintainability issues in JavaScript are scarce.Prior to the recent updates on the JavaScript language speciﬁcations, developers had to use cus-tom solutions to emulate classes, modules, and namespaces in JavaScript programs; consequently,detecting classes in JavaScript programs is non-trivial due to the ﬂexibility of JavaScripts syntax.To improve the maintenance and comprehension of JavaScript programs, we design and implementJSDeodorant , an automatic approach for detecting Function Constructors (i.e., the emulation ofObject-Oriented classes) in JavaScript programs. These function constructors can be declared lo-cally, under a namespace, or in other modules. The comparison with the state-of-the-art tool,JSClassFinder, shows that, while the precision of the tools are very similar (97% and 98%, respec-tively for JSDeodorant and JSClassFinder), the recall of JSDeodorant (98%) is much higher thanJSClassFinder (61%).Finally, we conduct an empirical study to compare the extent to which JavaScript programs indiﬀerent domains (websites, server-side programs written in NodeJS, and libraries) adopt Object-Oriented classes. Our study shows that classes are more frequent in websites than NodeJS programs.Also, NodeJS projects have fewer classes compared to libraries.iiiAcknowledgmentsFirst I want to express my sincere gratitude to my advisor Dr. Nikolaos Tsantalis for his guidanceall the way through the research. His patience, profound knowledge and motivation make me ableto improve my skills, to tackle diﬃcult obstacles and empower my willing to get this research done.Besides my advisor, I would like to thank my thesis examiners, Dr. Joe Paquet and Dr. WeiyiShang for their valuable time to read my thesis and for their invaluable comments. Other facultymembers of the Department of Computer Science and Software Engieering, specially Dr. EmadShihab and Dr. Peter C. Rigby, for providing the necessary guidance.I would like to thank Dr. Laleh M. Eshkevari for her valuable contribution in my thesis project.My special thank to my lab-mate and colleague Davood Mazinanian, for his continuous help inmy research and his great contribution for an Eclipse plugin written to help developers easily useJSDeodorant analysis engine.I would like to thank FQRNT, the Faculty of Engineering and Computer Science and FinancialAid and Award oﬃce at Concordia University for their generous ﬁnancial support of this project. Iwant to express my thankfulness to the staﬀ members of our university for keeping our environmentclean, safe and engaging.Last but not least, I am very thankful to my parents, for their love, sacriﬁces and their generousﬁnancial helps during my studies.ivContentsList of Figures viiiList of Tables x1 Introduction 11.1 Software Maintenance and Comprehension . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Object Oriented Programming in JavaScript . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Background 72.1 Emulating Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 JavaScript Namespace Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 JavaScript Module Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Literature Review 193.1 Does JavaScript Software Embrace Classes? [SRV+15] . . . . . . . . . . . . . . . . . 193.2 Normalizing Object-Oriented Class Styles in JavaScript [GACD12a] . . . . . . . . . 20v3.3 JSNOSE: Detecting JavaScript Code Smells [FM13] . . . . . . . . . . . . . . . . . . 213.4 An Analysis of the Dynamic Behavior of JavaScript Programs [RLBV10] . . . . . . . 233.5 Dont Call Us, Well Call You: Characterizing Callbacks in JavaScript [GMB15] . . . 253.6 Detecting Inconsistencies in JavaScript MVC Applications [OPM15] . . . . . . . . . 263.7 Development Nature Matters: An Empirical Study of Code Clones in JavaScriptApplications [CRK16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.8 JavaScript Errors in the Wild: An Empirical Study [JPZ11] . . . . . . . . . . . . . . 283.9 JavaScript: The Used Parts [GHWB14] . . . . . . . . . . . . . . . . . . . . . . . . . 304 Approach 314.1 Step 1: Parsing JavaScript Files and Building Model . . . . . . . . . . . . . . . . . . 314.1.1 Hierarchical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Step 2: Post-processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 Step 3: Binding Object Creations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.1 Simple Name Identiﬁer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.2 Composite Name Identiﬁer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.4 Step 4: Inferring Function Constructors . . . . . . . . . . . . . . . . . . . . . . . . . 375 Evaluation of Accuracy 395.1 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Precision and Recall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3 Comparison with the state-of-the-art tool . . . . . . . . . . . . . . . . . . . . . . . . 425.4 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Empirical Study 46vi6.1 Study Setup and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.3 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 Tool Demonstration 537.1 CLI Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 Eclipse Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 Conclusion and Future Work 60Bibliography 62viiList of Figures1 Function Constructor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Function Constructor with Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Object Literal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Similar Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Referring to JavaScript Files From HTML . . . . . . . . . . . . . . . . . . . . . . . . 127 Nested Object Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Immediately Invoked Function Expression . . . . . . . . . . . . . . . . . . . . . . . . 149 Immediately Invoked Function Expression With a Return Statement . . . . . . . . . 1410 Immediately Invoked Function Expression With a Parameter . . . . . . . . . . . . . 1511 An example illustrating the export and import in CommonJS style. . . . . . . . . . . 1612 An Example Illustrating the Export and Import in AMD Style. . . . . . . . . . . . . 1713 An Example Illustrating the Export and Import Using Closure Library Style. . . . . 1814 Overview of the Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 3215 Composite Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3316 An Overview of JSDeodorant Architecture . . . . . . . . . . . . . . . . . . . . . . . . 34viii17 Example of a Function Constructor JSDeodorant Failed to Identify . . . . . . . . . . 4218 Example of a Function in the Test Code That Was Not Annotated, but Added tothe Oracle as a Function Constructor. . . . . . . . . . . . . . . . . . . . . . . . . . . 4419 Analysis Result in The Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5620 Run Eclipse Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5721 Modules View Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5822 JSDeodorant Module Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5823 An Example of Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61ixList of Tables1 Characteristics of the Analyzed Programs. . . . . . . . . . . . . . . . . . . . . . . . . 402 JSDeodorant Precision and Recall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 JSClassFinder Results of Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Accuracy Measures for Both Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Number of Function Constructors in JavaScript NodeJS Program. . . . . . . . . . . 506 Number of Function Constructors in JavaScript Websites. . . . . . . . . . . . . . . . 517 Number of Function Constructors in JavaScript Libraries. . . . . . . . . . . . . . . . 52xChapter 1IntroductionJavaScript is the language of the web browsers [Cro08]. The language evolved from being in justclient-side to make HTML elements more interactive. Nowadays, JavaScript is used for server-sideprogramming [AMP16a], and also is adopted by emerging environments, across a wide range ofCloud Computing to Internet of Things [Pat]. It is the most used language on Github for threeconsecutive years since 2013 [Aly].JavaScript is built on some good and bad ideas [Cro08]. The language created in ten days byBrendan Eich in May 1995. The language was designed under conﬂicting forces of managers atNetScape to make the language like Java, to keep it simple for beginners and to have control oneverything in Netscape browser [Her12]. One of the issues with JavaScript is its global variableprogramming model. Everything in JavaScript is global, unless some actions are taken in orderto reduce global footprints. The more global variable a program has, the more chances of badinteractions (collisions) with other applications or libraries [Cro08].Crockford suggests using single global variable, which can be used by other variables or ob-jects as a container while other practitioners suggest diﬀerent techniques to leverage modularity inJavaScript such as closures.This chapter introduces the concept of object-orientation in JavaScript and motivation of thisthesis as well as the contribution and approach.11.1 Software Maintenance and ComprehensionMaintenance is an important part of a software life cycle. Following software release, there is aneed for improvements such as performance boost, ﬁxing new defects or changes for adaptabilityto a changed environment. Preserving software integrity while making changes to software is theobjective of maintenance [SBF14]. McKee [McK84] claims two thirds of a programmer activity at-tributed for maintenance of existing parts. An estimation of 50% of total life cycle cost is associatedwith the maintenance part [vV08].Various techniques have been introduced to be used in software maintenance, including programcomprehension, re-engineering, reverse engineering, migration and retirement [SBF14]. Diﬀerentcomprehension tools address diﬀerent levels of a problem. Program slicers, static analyzers, dynamicanalyzers and dependency analyzers are among the well known tools used by practitioners.Spending considerable time on program comprehension (including reading source code and doc-umentation) to be able to apply changes by programmers, makes tool makers and researchers todesign code browsers and code visualizers to alleviate the diﬃculties of understanding source code.There are still lots of gaps that should be addressed and with JSDeodorant , we are trying to helpdevelopers better understand JavaScript programs to overcome barriers of comprehension in thelanguage.We designed and implemented a developer aided tool, JSDeodorant , which presents a state ofthe art static source code analysis which aim at identifying class-like structures in JavaScript thatdevelopers use to improve re-usability and utilizing object oriented practices adapted from knownprogramming languages such as Java and C++.1.2 Object Oriented Programming in JavaScriptIn early nineties, object-oriented programming found its way to industry. It was a combination ofdiﬀerent ideas which were previously conceived and accepted by the software community. Howeverthis time it was in the form of books, courses and programming languages which were built on topof this phenomena. Many developers think of object-oriented as the key to most of the problems,and if a system does not obey accepted principles in object orientation, it would be consideredinferior [Hav14].2Object oriented programming is a paradigm which an object as the main entity, is a representa-tive of data and behavior known as attributes and methods, respectively [KK11]. Mozilla DeveloperNetwork [Moza] deﬁnes OOP as a mean of abstraction over the real world. Modularity, polymor-phism and encapsulation are predecessor which all of them can be found in OOP. Objects cansend and receive messages to each other and process diﬀerent data by themselves. OOP promotesunderstandability and maintainability if it is used properly. Class-based programming is one of themost known styles of object-oriented programming.JavaScript, on the other hand, is a prototype based language, but to overcome the complexityof implementation in diﬀerent scenarios and to increase the reusability of diﬀerent components,developers rely on non-standard JavaScript’s class abstraction [SRV+15].Following object oriented deﬁnitions quoted from Mozilla Developer Network [Moza] and wewill use these terms throughout this thesis:• Namespace:A container which lets developers bundle all functionality under a unique, application-speciﬁcname.• Class:Deﬁnes the object’s characteristics. A class is a template deﬁnition of an object’s propertiesand methods.• Object:An instance of a class.• Property:An object characteristic, such as color.• Method:An object capability, such as walk. It is a subroutine or function associated with a class.• Constructor:A method called at the moment when an object is instantiated. It usually has the same nameas the class containing constructor.3• Inheritance:A class can inherit characteristics from another class.• Encapsulation:A method of bundling the data and methods that use the data.• Abstraction:A technique in computer science to hide the complexity of a given component using methods,attributes, inheritance and etc.• Polymorphism:Poly means “many” and morphism means “forms”. Diﬀerent classes might deﬁne the samemethod or property (implementing an interface), but leaving the implementation details toconcrete types. Knowing that which of the implementations will be called is deferred to theruntime.There are diﬀerent ways that programmers leverage modularity in the source code. One ofthe ﬁne-grained and well understood techniques for achieving modularity is using object orientedclasses. Besides classes, another type of OOP could be of prototype-based programming. Prototypestyle does not used classes, however it is using existing prototype objects to achieve the desiredbehavior by decorating them for reusability purpose.Every JavaScript object has a prototype, which again is an object. Properties and methods ofan object will be inherited by children objects. Despite the fact that JavaScript is a prototype-basedlanguage, it has indirect support for classes (No syntactical support for class, but there are diﬀerentemulation techniques for classes). However, lacking of a syntactical support for declaring a class ordeﬁning a module in JavaScript prior to the recent update on the language speciﬁcation1 [Ecm15],makes developers employ diﬀerent strategies to emulate classes and modules.1.3 MotivationThere is an imminent growth to JavaScript popularity [AMP16b]. This growth makes JavaScripta programming language that can implement a sophisticated business application or to be used1ECMA-262 Edition 6, approved on June 17, 2015 oﬃcially adds support for JavaScript class and module.4for creating an interactive user interface. Further development and maintenance of such programsrequire good tool support for assisting developers better understand source code [vMVH97].Silva et. al. [SRV+15] developed a tool, JSClassFinder, to identify class-like structures inJavaScript. Based on their ﬁndings they divided JavaScript programs into four types of programsregarding class-like structures: class-free (systems with no class at all), class-aware (programs thatuse classes marginally), class-friendly (programs with relevant usage of classes) and class-oriented(systems with major usage of classes). However they did not evaluate JSClassFinder accuracy interms of precision and recall. Thus we extend this work by addressing its current limitations andbuild an oracle to enable the evaluation of accuracy for their tool against ours. The most importantlimitations of their work are as following:• The do not support ﬁnding classes that are in nested hierarchies such as namespace• Without instantiation, their tool is not capable of ﬁnding function constructors, it meansJSClassFinder cannot infer classes.Another aspect of software comprehension, is providing a good tool support in IDE to assistprogrammers. There is a great possibility to improve existing tool support in IDEs. Limitedsupport by Eclipse and its JavaScript source code analysis tool (JSDT) for navigation and outliningJavaScript programs, makes JSDeodorant plugin a valuable asset for JavaScript developers.A tool with a known accuracy can be employed to facilitate the automatic migration of existingJavaScript code to the new version of ECMAScript with explicit support for class declaration. Thisthesis aims at automating the process of source code analysis with integrating it to Eclipse by givingthe user a power of navigating between diﬀerent modules and also depicting UML class diagrams.1.4 ContributionsThis thesis introduces JSDeodorant , an Eclipse plugin that combines and extends the previoustechniques to detect functions emulating class behavior in JavaScript. JSDeodorant is also able toidentify module dependencies and supports code navigation from the object instantiations to theirclass declaration. The main contributions of this work are:• A technique for identifying class emulations at diﬀerent levels of granularity: within ﬁles,namespaces, and modules.5• An automatically-generated (and thus, unbiased) oracle that enables replication by othertools, and tool comparison. We also did a quantitative and qualitative evaluation of theresults to identify our current limitations and opportunities for future improvements.• A comparison of our technique with the state-of-the-art tool JSClassFinder [SRV+15].6Chapter 2BackgroundTraditional programming languages use constructs (e.g., classes, modules) for improving codereusability and encapsulation. Code reuse decreases redundancy in the code (known as clones),and encapsulation reduces the risk of exposing implementation details. JavaScript developers tendto use diﬀerent techniques to achieve code modularity.As mentioned, lack of syntactical support for declaring classes, modules, and namespaces inJavaScript prior to the recent updates on the language speciﬁcation, forces developers to employdiﬀerent strategies to emulate them. In the following sub-sections, we brieﬂy discuss some of thestrategies introduced and promoted in the JavaScript community [Osm12, Cro08, Stab, Tru]. Itshould be noted that due to the inherent ﬂexibility of JavaScript language, developers are able tofollow diﬀerent strategies for emulating the mentioned constructs, which makes the maintenance ofJavaScript programs a non-trivial task.2.1 Emulating ClassesIn JavaScript, functions are ﬁrst-class entities of type Object 1, i.e., a function can be passed asan argument to other functions, returned by other functions, or stored as a value in a variable.Moreover, functions can have methods and properties themselves [Mozb].JavaScript developers use functions to emulate the behavior of object-oriented classes. In this1In JavaScript, all values, except primitive values are inherited from Object.7case, JavaScript functions are used as constructors and methods of classes. Thus, we diﬀerentiatebetween three types of roles in which a function can serve in JavaScript, following Gama et al.[GACD12b]:• Function constructors: In JavaScript, it is possible to deﬁne functions and variables thatbelong to another function. Such a function is called a function constructor, and correspondsto the constructor of an object-oriented class. Accordingly, functions and variables deﬁnedfor this function constructor are the methods and attributes of that class, respectively. As wewill see, there are alternative ways to deﬁne functions and variables that belong to a functionconstructor. In this thesis, the terms class and function constructor are used interchangeably.• Methods: We refer to a function that belongs to a function constructor as a method. Amethod can be declared within the body of a function constructor or added to the prototypeof the function constructor.• Functions: Finally, all other routines (i.e., normal functions) are considered as functions.Thus the concept of class provided by major object oriented languages can be achieved by func-tions in JavaScript. Use of object literals in JavaScript is another way to provide a semi-class likebehavior when developers require singleton classes. Deﬁnition 1 and 2 bellow explain the functionand singleton based constructs respectively.Deﬁnition 1 (Non-singleton classes: Function Constructor)A simple function declaration can be a function constructor if it is preceded by new keyword in thecall site. Then a new empty object of type function will be created and the this keyword inside thefunction bounds to the new object being constructed [Ecm11] [Mozc]. Two common approaches fordeclaring function constructors are listed in Figure 1.A and 1.B.For declaring properties and methods, developers use the this keyword or use function construc-tor’s prototype (prototype is usually used for deﬁning methods). As shown in Figure 1, propertyfoo and method bar are deﬁned in the class body. Unlike conventional object oriented languageswhich provides implicit this scope, a JavaScript class must refer to its own properties and methodsusing this keyword explicitly. JavaScript does not provide access modiﬁer for class members, soeverything is always public and accessible in global scope, unless some actions are taken to make8function TheClass() { this.foo = 0; this.bar = function() { console.log(this.foo); }}var TheClass = function() { this.foo = 0; this.bar = function() { console.log(this.foo); }}var theInstance = new TheClass();theInstance.foo = 2;theInstance.bar(); // 2A BC123456123456123Figure 1: Function constructor can be a function declaration (A) or an anonymous function expres-sion assigned to a variable (B), the instantiation remains same for both cases (C)them private using some namespacing techniques, which we will explore in Section 2.2 where weare discussing about immediately invoked function expressions (IIFE).Figure 2 shows an equivalent example of a JavaScript class where the method assigns to theprototype of class, instead of beings assigned to this within in the body of function constructor.function TheClass() { this.foo = 0;}TheClass.prototype.bar = function() { console.log(this.foo);}var TheClass = function() { this.foo = 0;}TheClass.prototype.bar = function() { console.log(this.foo);}var theInstance = new TheClass();theInstance.foo = 2;theInstance.bar(); // 2A BC123456123456123Figure 2: Function constructor where the method is assigned to prototype rather than this keywordwithin the class bodyIt is very important to note that function bar is still accessing ﬁelds and other methods of aclass i.e.,foo using the keyword this, despite the fact that the deﬁnition of methods is not locatedwithin the function constructor’s body. In Section 6 we will show how important it is to supportsuch a style of deﬁnition, because developers are using this style in many cases.Noteworthy, declaring methods outside the function constructor’s has many beneﬁts includingbut not limited to [Staa]:9• Ease of modiﬁcation method behavior Changing the method behavior in the run-timeis just as simple as changing it once – that means the developer is not obligated to changemultiple places to have uniﬁed behavior among instances of class.• Performance Putting a method inside the the constructor leads to poorer performance (i.e.,Figure 1). So, a method needs to be created whenever an instance of a class is created, but ifthe method has been created on top of the prototype chain (i.e., Figure 2), it will be inheritedby each instance rather than being created multiple times.Deﬁnition 2 (Singleton classes)There are various techniques to emulate singleton classes. We will explore two diﬀerent, yet popularways of declaring singleton classes. The ﬁrst style uses built-in JavaScript object literals to deﬁnea class. Figure 3.A shows how a singleton class can be deﬁned by object literal.In JavaScript, the object literal is a list of key-value pairs where each value can be of any datatype such as object literal, function, or array literal. It is denoted by an open and a close curlybracket, where the functions and variables deﬁned inside them are essentially the methods andattributes of that object, respectively. One of the major diﬀerences between object literal andfunction declaration style (i.e., 3.B) is, the new keyword is not required for creating an instance ofthe object literal. In contrast, we can pass arguments to a function constructor while object literalstyle does not provide this functionality.var singletonClass ={ foo: 0, printIt: function(){ console.log(this.foo); }}singletonClass.foo = 5;singletonClass.printIt(); // 5A123456 BCvar singletonClass = new function(){ this.foo = 0; this.printIt = function(){ console.log(this.foo); };}12345612Figure 3: An instance will be created immediately without the need of new keyword.Another way of having a singleton class is using a combination of new and function keywords.If the new keyword precedes an anonymous function expression, the function constructor is formed10with a speciﬁc behavior: new keyword is going to be invoked once (singleton), to create an emptyobject. Figure 3.B shows an implementation example of this technique.Taking the fact into account that these variations may be combined with many other techniques(namespacing) to achieve better encapsulation makes the identiﬁcation of these structures a non-trivial source code analysis task. Diﬀerent namespacing techniques suggested by practitioners inindustry and above-mentioned emulation patterns may aﬀect the precision of a static source codeanalysis tool for ﬁnding classes in JavaScript codes. In Section 2.2, we explore various namespacingtechniques posed to developers for achieving a higher level of modularity.2.2 JavaScript Namespace EmulationMost of the traditional programming languages provide mechanisms for grouping semantically-related concepts (e.g., classes and ﬁles). Examples are packages and namespaces, that provide abetter organization for the code and also help in avoiding name collisions. In JavaScript, mimickingthe behavior of a namespace can be done in diﬀerent ways [Osm12].An example of a JavaScript program containing a variable and a function declared in globalnamespace shown in Figure 4.// global scopevar myGlobalVariable = 1;function sayHello(){ console.log(myGlobalVariable);}sayHello();123456Figure 4: variable myGlobalVar declared in the global scope.Both variable myGlobalVariable and function sayHello are in the global scope of such a program.Having that said, now let us assume we have two diﬀerent ﬁles, i.e., Sales.js and Orders.js withdiﬀerent functionalities. These two ﬁles provide a method (in the global scope) to return a list ofsales and orders respectively. Figure 5 shows these two ﬁles containing a function with an identicalname.11A B// Sales.jsvar getList = function() {// do something here}// Orders.jsvar getList = function() {// do something here}12341234Figure 5: function with name getList exists in both ﬁles which returns appropriate result forcorresponding ﬁle.In the production code, when the two ﬁles Sales.js and Orders.js are included in the HTML ﬁle(Figure 6), invocation to getList() will lead to a name collision. Interpreter fails to understand bygetList() which one of the deﬁnitions should be resolved. Hence name collision occurs.123456789Figure 6: adding external JavaScript ﬁles into a single HTML ﬁle in production codeThere is also a best practice in client-side code deployment, which recommends concatenationof all JavaScript source ﬁles into a single one, to make it more suitable for the browser to reducethe number of HTTP requests over network (Round-trip). In those cases, JavaScript is more errorprone in terms of variable or generally, identiﬁer collisions.Previous releases (prior to version 1.6) of JavaScript do not provide direct (syntactical) supportfor namespacing, and thus to avoid conﬂicts developers combine diﬀerent language constructs toachieve namespace emulation.In the following two sub-sections we brieﬂy describe two common approaches used to avoid nameconﬂicts.Approach 1- Nested object literals:The ﬁrst and easiest way is to use nested object literals. Figure 7 shows how to form a nestedobject literal with a class declaration in its deepest level. To create an instance of a class, the call12site should provide a full path to the function declaration (function constructor).var namespace = { module: { subModule: { TheClass: function() { this.foo = 0; this.printIt = function() { console.log(this.foo); } }, AnotherClass: function() { // Body of another class } } }};var theInstance = new namespace.module.subModule.TheClass();theInstance.foo = 7;theInstance.printIt();12345678910111213141516171819Figure 7: Nested object literals form a namespace for enclosing class, TheClass.A composite identiﬁer follows the new keyword to access TheClass for instantiation and preventsit to be exposed to the global scope. Now, only namespace is a global object and other nested objectsincluding module, subModule, TheClass, and AnotherClass are wrapped in namespace. This is oneof the simplest ways to deﬁne namespace and is widely used in open-source JavaScript programs.Approach 2- Immediately-invoked Function Expressions (IIFE): IIFE refers to a functionthat is invoked right after it is declared. The self-invoked function only runs once and all variablesand functions declared within the body of such namespace are by default private unless some actionsare taken to expose them outside [Osm12], which we will explain in details. An example of IIFEis shown in Figure 8. The ﬁrst pair of parentheses (function() { ... } ) transforms the code intoan expression, and the second pair of parentheses (function() { ... } ) () calls the function thatresults from that expression [Stac].As shown in Figure 8, the function foo is not exposed to the outside of IIFE. The only diﬀerencesbetween the following techniques is how to expose members within IIFE to the outside.13(function(){ // all your code here var foo = function() {}; window.onload = foo; // ...})();// foo is unreachable here (it’s undefined)1234567Figure 8: Immediately Invoked Function ExpressionExpose members using return statement: To expose private members of an IIFE, devel-opers use the return statement to return an object containing variables and functions. In Figure var theClassInstance = new namespace.PublicClass(); // I am a classA BCvar namespace = (function() { var template = {}; template.myProperty = 0; template.PublicClass = function() { console.log('I am a class'); } return template;})();var namespace = (function() { var classDeclaration = function() { console.log('I am a class'); } return { myProperty : 0, PublicClass : classDeclaration };})();123456781234567891Figure 9: Immediately Invoked Function Expression With a Return Statement9.A, the function constructor PublicClass is assigned as a property of an empty object with nametemplate and then that object is returned by the return statement. As a result of the evaluation ofthis IIFE, the rvalue of the return statement (i.e., return foo; where foo is the rvalue) within thefunction will be stored into the variable with name namespace which is in a global scope.To create an instance of PublicClass, one should provide the qualiﬁed name as namespace.PublicClasslike the instantiation in Figure 9.C.If the namespace object is already exist in the global scope, there should be a work-around tocheck and use existing object rather than creating a new object. Expressions such asvar namespace = namespace ‖ {}; would be a help to prevent overriding existing objects.In case developer needs to verify if an object exists or not (above-mentioned expression), it14should be convenient for a developer to be able to augment an existing object, rather than creatingnew object for namespace.For such scenarios, it is suitable to pass the namespace object to IIFE and assign methods andproperties directly to that object. This way neither return statement nor creation of an emptyobject is required. Figure 10.A shows a case where a parameter can be passed to IIFE, and usedas a container for methods and properties. var theClassInstance = new namespace.PublicClass(); // I am a classA BCvar namespace = {};(function(ns) { ns.myProperty = 0; ns.PublicClass = function() { console.log('I am a class'); }})(namespace);var namespace = {};(function() { this.myProperty = 0; this.PublicClass = function() { console.log('I am a class'); }}).apply(namespace);123456712345671Figure 10: Immediately invoked function expression add methods and properties to a parameter(A) and to keyword this (B) which is equivalentAnother approach instead of using ns within the body of the IIFE in Figure 10.A, would be theuse of built-in function apply to assign the this keyword to the passed argument. In JavaScript,calling apply() on an object that references a function, results to invoking that function, and thethis object belonging to the called function is bound to the apply()’s ﬁrst argument. Consequently,in Figure 10.B, the this object in the anonymous function is bound to namespace, and therefore,PublicClass will belong to namespace. The instantiation remains same for both cases A and B asshown in Figure 10.C.2.3 JavaScript Module PatternJavaScript used to lack a mechanism for importing classes and functions from other JavaScriptﬁles. However, JavaScript community has proposed diﬀerent approaches for deﬁning JavaScriptmodules (i.e., ﬁles that can be imported to other ﬁles). The two most popular module systems are15CommonJS [Com] and AMD 2 [AMD]. The former is designed to be more suitable for server-sideJavaScript, while the latter is used mostly client-side JavaScript. There is also a more domainspeciﬁc style developed by Google Closure Library [Clob] team, which has been used widely in theirlibrary.CommonJS:In CommonJS, a JavaScript module can expose all or parts of its behavior as an API, by settingthe exports property.A// csv.jsvar Writer.=.function(filename) {// create csv file ...}Writer.prototype.write.=.function(content).{// write the content to file}module.exports.Writer = Writer;12345678 B// usage.jsvar csvModule.=.require('./csv');var csvWriter.= new.csvModule.Writer('test.csv');csvWriter.write('hello, world!');1234Figure 11: An example illustrating the export and import in CommonJS style.In Figure 11-A, the module csv.js exports the variable Writer at line eight, referencing afunction constructor.Likewise, a JavaScript module can access other modules’ APIs by invoking a call to the requirefunction. The function accepts a module identiﬁer as its argument, and returns the exportedAPIs of the imported module. The module identiﬁer can be speciﬁed by the module’s name, orthe path/URL to the JavaScript ﬁle where the module is deﬁned in, or a path/URL of a foldercontaining a set of modules (i.e., a package). In Figure 11-B, usage.js imports features thatare exposed in the module csv.js (line two). At line three, an instance of Writer is created byaccessing the csvModule’s exposed function constructor.Asynchronous Module Deﬁnition (AMD):Module pattern proposes a module pattern that supports asynchronous loading for both themodule and its dependencies [Stae]. Like CommonJS which has module.exports and require, thetwo most important idea for AMD style is deﬁne method for exposing module deﬁnitions andrequire method for handling dependencies. Figure 12 shows the syntax of deﬁne and require whichis slightly diﬀerent from CommonJS style but signiﬁes similar semantic.2Asynchronous Module Deﬁnition16A// package/lib is a dependency we requiredefine(["package/lib"], function (lib) { // behavior for our module function foo() { lib.log("hello world!"); } // export (expose) foo to other // modules as foobar return { foobar: foo }});123456789101112 B// Somewhere else the module can be // used with:require(["package/myModule"], function(myModule) { myModule.foobar();});12345Figure 12: An Example Illustrating the Export and Import in AMD Style.As illustrated in the code comments, in Figure 12.A we have the deﬁnition of module, whichitself, requires another module with name lib which is located in relative path package folder. Inline 4, we have the deﬁnition of function foo but it is not yet exposed to the outside. Line 9 showshow developer can export private members within the deﬁne function by using the return statementwhich in this example is function foo.In Figure 12.B another module tries to import above-mentioned module with the use of requirefunction. A parameter of the require function will be injected by the interpreter with the corre-sponding deﬁnition (i.e., object containing foo). It should be noted that the imported object is notthe function foo, it is rather an object containing foo which is wrapped by the created object literalin Figure 12.A following return statement in line 9.Closure Library Modules:Similarly, for exposing behavior or part of the module, a function call to goog.provide is necessary.The argument to this module should be identical with another or other module’s import (to bespeciﬁc: goog.require) argument. In Figure 13 line 1, it is speciﬁed that this ﬁle is exposing amodule with name goog.async.run and in line 3 and 4 it is dictated that this module requires twodiﬀerent modules with names goog.async.WorkQueue and goog.async.nextTick.In line 6, it should be noted the module assigns the corresponding function declaration to asimilarly named identiﬁer, which previously (line 1) speciﬁed as the provide’s argument. When amodule manifests it requires this module, the function declared in line 6 is exposed to call-site andis responsible for execution in the run-time.17goog.provide('goog.async.run');goog.require('goog.async.WorkQueue');goog.require('goog.async.nextTick');goog.async.run = function(callback, opt_context) { // ...};12345678Figure 13: An Example Illustrating the Export and Import Using Closure Library Style.18Chapter 3Literature ReviewDespite the fact that JavaScript is used widely both for client-side and server-side programming,there seems to be remarkably little other work related to JavaScript source code analysis. Thefollowing nine papers give us information about how they analyze source code.3.1 Does JavaScript Software Embrace Classes? [SRV+15]Silva proposed an automatic approach, JSClassFinder, that identiﬁes class deﬁnitions by analyz-ing the instance creation statements (statements using the new operator). They deﬁne functionconstructor as a function where the invocation consists of an instantiation and they conduct an em-pirical study on 50 popular JavaScript applications obtained from Github with the aim at answeringwhether JavaScript developers use classes or not and to see if they are using inheritance.To the best of our knowledge, their research is the most relevant to ours but one of the limitationof JSClassFinder is the lack of support for classes deﬁned in nested namespaces (composite names).Moreover, classes are matched by their names regardless of the ﬁle dependencies, leading to incorrectmatches when diﬀerent ﬁles contain classes with the same name, and ﬁnally their approach fails toidentify classes that are not instantiated.JSClassFinder follows static source code analysis technique, which is applied through a searchfor matching names between the operand of new expression and function declarations (known asfunction constructors). They extract Github projects that ranked with at least 1000 stars and have19at least more than 150 commits. Then they remove all miniﬁed1 ﬁles, copyright and documentationﬁles with .js extensions.They found class declarations in 37 out of 50 systems (74%). For the systems containing classes,34% of them have more attributes than methods (those classes are more like data classes), and theyspeculate it is more likely JavaScript developers are placing less importance on encapsulation (i.e.,getters and setters are rare in JavaScript)It is concluded that there are four types of systems in JavaScript. class-free systems that do notmake any usage of classes, class-aware systems that make rare use of classes, class-friendly systemswere use classes relevantly, and ﬁnally class-oriented systems that have vast majority of uses interms of class like structures. They also concluded that there is no signiﬁcant co-relation betweensize of the corpus and class usage. They hypothesize that developers’ background and experienceimpacts the usage of classes rather than the project’s size.3.2 Normalizing Object-Oriented Class Styles in JavaScript[GACD12a]The intention of this work is to increase stylistic consistency and improve maintainability of objectoriented JavaScript applications by normalizing the representation of classes into a single model.Authors discuss that JavaScript is a prototype-based language and lacking of an explicit classdeclaration to deﬁne ﬁelds and methods has led to a plethora of diﬀerent class representationtechniques.They list three of the diﬀerent styles that developers may use to mimic class declaration inJavaScript despite the fact that they are almost identical semantically and this diﬀerence canlead to stylistic inconsistency issues. The ﬁrst style is closest to the conventional object orientedlanguages. The function Class acts as both class deﬁnition and the constructor.The second style uses the function prototype object which, prototype of constructor function isan anonymous that is stored in the variable Class. The initialization moved to the code followingconstructor call.The third one is similar to the above mentioned samples as it uses Class variable and anonymousfunction but assigned the method m to the prototype of the object. This way all objects created1The process of removing unnecessary characters from code with preserving semantic is called miniﬁcation20using the Class constructor function will share the m across the program.They use the TXL Programming Language developed to support source transformation withan existing grammar for parsing JavaScript to pattern match source code. They merge each andevery JavaScript ﬁle into one ﬁle with snippet of automatic comments to identify the original ﬁleboundaries. They recognize various object class styles and mark them for transformation to apreferred style. According to the survey on several tutorials, books and a large set of over 70production JavaScript applications, Prototype Lambda is selected as the preferred style. After theyhave identiﬁed all of the classes and method functions in source codes, normalization transformationis carried out by another TXL program for changing them to the Prototype Lambda style.They found real world applications are using diﬀerent styles of those described in books andtutorials, that are more elegant and robust.They found some applications were already using the target pattern, prototype lambda, thustransformation would not apply on them. Interestingly the other applications has four diﬀerentpatterns, that makes the project hard to maintain and inconsistent in style.From this study it was found out that there are many diﬀerent styles for class declaration thathas been used interchangeably in real world applications. It can also concluded that developersare adopting some object oriented principles in this language like classes, encapsulation and inher-itance(using prototypes) despite the fact that there is no direct language support for them. Weadopt their technique to infer classes in JavaScript without the need for instantiation.3.3 JSNOSE: Detecting JavaScript Code Smells [FM13]JSNOSE tool combines static and dynamic analysis on JavaScript to gather adequate informationto detect code smells. Authors deﬁne code smells as indication of potential comprehension andmaintenance issues in JavaScript. Detecting code smells manually is tediously time consuming anderror-prone. Lacking of a sophisticated smell detection tool for JavaScript, authors provide a toolto overcome the highly dynamic nature of the language.Smell detection process of many object oriented languages is dependent on identifying objects,classes and functions inside the code and unlike languages such as Java or C++, identiﬁcation ofsuch language elements is not straightforward in JavaScript. Besides theoretical contributions theymade in this paper, one of the valuable impacts of their work is the implementation of research into21an open source tool, which aims to ﬁnd code smells. The tool is evaluated through an empiricalstudy over 11 real JavaScript web applications. The contributions of this tool results in decreasinglongterm development cost and increasing the chance of project success by helping developersimprove maintainability of the code.Among diﬀerent code smells mentioned in both object oriented languages and JavaScript re-sources, they choose 13 speciﬁc code smells: 7 of them are existing prevalent object oriented smellsadapted to JavaScript and the rest of them are speciﬁc JavaScript smells. They use a metric basedapproach, which is generic in almost all object oriented languages.Consequently the threshold values are selected based on studies performed in other object-oriented languages. By performing static analysis and traversing abstract syntax tree (AST) theygather information about objects, properties, inheritance relations, functions, and code blocks.Their approach for using static analysis is very useful speciﬁcally for local objects and variableswithin functions, because they are not available in the global object during execution. Dynamicanalysis is used in order to monitor object creations or updates at runtime and also to ﬁnd un-used/dead code for measurement purpose by code instrumentation.The result indicates that lazy object, long method/function, closure smells, coupling betweenJavaScript and HTML and excessive global variables are the most prevalent code smells.Their work indicates that source code analysis on JavaScript is not as easy as major objectoriented languages. It provides some key features of other programming languages, but the wayit behaves diverged from well-known object oriented languages. An example of this diﬀerence isprototype chains which somehow resembles inheritance in other languages with an exception that inJavaScript, programmer can create and modify existing object prototype at runtime. That meansredecoration of object hierarchy during execution.Unlike their approach, we can only rely on information gathered based on static analysis. Wethink it is possible to augment JavaScript weakly-typed system to infer unknown types without theneed for code instrumentation and other types of analysis such as dynamic and symbolic execution.The limitation of their work is that they need to gather information during execution which cannothelp programmers to ﬁnd code smells during development phase.223.4 An Analysis of the Dynamic Behavior of JavaScript Pro-grams [RLBV10]In this paper they did an empirical study on a large corpus of widely-used JavaScript programsto measure how and why the dynamic features of the language are used by programmers. Theyalso measure the degree of dynamism in such programs. Moreover they made a good comparisonwith assumptions that are generally made within JavaScript communities in both industry andacademia.Due the magnitude of growth of using JavaScript in the real world web applications and alsogradual increase in using JavaScript as a general purpose language for developing tools and libraries(running on server-side such as Node.js) it has taken academic attention. They characterized andproduce behavioral data of JavaScript program by code instrumentation to obtain run-time tracesof 103 web sites.The main motivation behind their work is to assess feasibility of the static type system to applytype checking on existing JavaScript programs. They argue that existing techniques generally relyon minor simpliﬁcations, for instance one approach make the following assumption: “Usually, nofurther properties are deﬁned after the initialization and the type of them rarely change” or Google’sV8 engines is reported to optimistically associate classes to objects on the assumption that theirshape will not change too much.Their instrumentation tool integrates with Safari, browser from Apple, to capture traces con-sisting of DOM, AJax and purely JavaScript code that is stored in a database for following steps.Traces were compressed and store on disk without noticeable impact on live interactions in pro-grams. Traces were stored in a database for further several static analyses using Mozilla RhinoJavaScript parser. The good point in their research is that they handle eval function calls as it issimilar to load new source ﬁle.Results of their study classiﬁed into two major branches. Firstly, static analysis is done to ﬁndfollowing metrics:• Corpus size• Instruction Mix• Prototype Chains23• Object KindsAnd the second part lay down in measuring program dynamism for the following metrics:• Call site dynamism• Function Variability• Uses of eval• Object protocol dynamism• Constructor polymorphism• Constructor prototype modiﬁcation• Changes to the prototype chains• Object lifetimes• The eﬀects of JavaScript librariesBased on the results, they evaluate assumptions that are made in the JavaScript communityand argue that most of them are not true in real-world projects.What we can infer from the results to make sure about our approach regarding static analysisis as following: the prototype hierarchy is invariant. Moreover, properties are added at objectinitialization and also they are rarely deleted. In most languages, variadic functions are rare, andbased on this study nearly 10% of functions are variadic in JavaScript. It means that declaredfunction signatures are indicative of types. Call-site dynamism is low which means that the level ofpolymorphic call sites are only 19% and monomorphic call sites are dominant in almost all projects.With respect to the results of this study we can eliminate dynamic analysis and just improvestatically analyzed precision of our research. With comparison with A. M. Fard and A. Mesbah’s[FM13] approach, we can ﬁnd out that there is no explicit need to have dynamic analysis formonitoring all object creations and modiﬁcations during runtime because they are not that muchprevalent in real world applications.243.5 Dont Call Us, Well Call You: Characterizing Callbacksin JavaScript [GMB15]Authors of this paper try to understand callback usage in real-world JavaScript programs. Call-backs are one of the core successful features of this language and this feature owes its existence inJavaScript to the way that it deﬁnes functions. Functions are ﬁrst-class objects which make it ableto be saved in a variable, to be passed as an argument to other functions and so on. They studied138 corpus of JavaScript programs dividing into two major category: 1) Server-side codes knownas Node.js projects and 2) Client-side code which runs in the browser. The result of this researchhelps to show the language designers on how developers are using callbacks and tool builders toﬁnd good solutions to be able to get rid of excessive and nested callbacks known as callback hell.JavaScript callback is very important because it is playing an important role. For example it isused to service multiple concurrent client requests on server-side. On the client-side, responsivenessof user interface controls are feasible because event-model system can be implemented using callbackmechanism. Usage of callbacks is important because JavaScript comprehension and maintainabilityis correlated to the usage of callbacks. They study how often are callbacks used and in what extentcallbacks are prevalent in client or server-side codes.They design and implement a static analysis tool to identify diﬀerent styles of callback patternsused by JavaScript developers. They built a tool on top of existing tools to generate AST, walkthrough it and a type inference engine to ﬁnd parameter types to distinguish simple parametersfrom parameters that accept a function. Out of 138 open source projects, 86 of them were NPMNode’s packages, 16 web applications, 16 game engines, 8 client-side framework and 6 visualizationlibraries.For over 5 million lines of code in total, they found out of 10 functions, one of them accepta function as a parameter. Over 43% of callbacks were anonymous and majority of callbacks arenested to other callbacks. Most of the nested callbacks appear in client-side code with 72% thanserver-side with 55%. Error-ﬁrst protocol was among the most popular techniques to overcomediﬃculties related to callbacks. The other two major solutions are Async.js and Promises.They found that over half of all callbacks are named (not anonymous). They concluded that allJavaScript program that handle and response to events are using callbacks. These programs suﬀerfrom excessive callbacks which reduce the comprehensibility and maintainability of source code.253.6 Detecting Inconsistencies in JavaScript MVC Applica-tions [OPM15]Maintaining consistency among emerging MVC 2 frameworks in JavaScript platform makes authorsof this paper to design and implement a tool, named AUREBESH that automatically detectsinconsistencies between Model, View and Controller of such applications. In their previous work[OBPM13] they found majority of JavaScript bugs are DOM-related 3 ones. DOM related bugs arerelated to the interaction between HTML, CSS and JavaScript. Bugs that MVC frameworks areclaiming that this pattern would help developers reduce the complexity of working with DOM indiﬀerent scenarios, and such bugs are more often result from developer’s incomplete understandingof the relationship between JavaScript and DOM.Despite the fact that MVC frameworks are created to solve such problems, they are still vul-nerable to DOM-JavaScript interaction bugs. They further explain that these frameworks rely onuse of identiﬁers to connect model objects, controller methods and view’s ﬁeld accesses to model.The main problem arises because JavaScript is loosely typed. When developer change the name ofa method or generally an identiﬁer, consistencies will not throw mismatch or undeﬁned compiled-timed exceptions. To tackle such a problem they create a static analysis tool to identify variablesand methods in these diﬀerent components (model, view and controller) and then they try to inferthe type of those identiﬁers to ﬁnd inconsistencies.They opt for static analysis in this work. And throughout their work, they have a workingexample inspired by one of these popular MVC frameworks (AngularJS), however they claim thattheir technique can be extended to all MVC frameworks. They extract model variables and con-troller functions and then they apply type inference techniques to ﬁnd the type assigned to a modelvariable in the model or controller by inspecting the right-hand side of assignment expressions. Sotheir tool is capable of identifying both identiﬁer(name) and type inconsistencies.They did an empirical study on 11 JavaScript applications and in total their tool found a totalof 15 error messages. Of these 15 errors, 13 of them were identiﬁer inconsistencies and 2 typeinconsistencies. They categories following patterns for faults:• Identiﬁer deﬁned elsewhere (found in 7 cases)2Model, view and controller3Document object model26• Incorrect identiﬁer (found in 5 cases)• Boolean assigned a string (found in 2 cases)• Identiﬁer name not updated (found in 1 case)They only found one false positive due to a misleading (corner case) alias in one of the appli-cations. Their tool indicates their approach is very accurate in ﬁnding inconsistency in JavaScriptMVC framework applications. They reach to an overall 96.1% recall and a precision of 100%. Thetool is useful in detecting bugs, which help researchers of this work to ﬁnd 15 real-world bugs inapplication built on top of AngularJS, which is a popular JavaScript MVC framework.3.7 Development Nature Matters: An Empirical Study ofCode Clones in JavaScript Applications [CRK16]The authors mainly investigate:• Clone properties in diﬀerent languages (Java and JavaScript) and application domains (JavaScriptstand-alone projects(JSproj) and JavaScript web applications(JSweb)).• Correlation between clone properties and software metrics and comparing this relation indiﬀerent languages and application domains.• Identifying development practices in Java, JSweb, and JSproj.One of the active research areas in software is code clones [TMK15]. Researchers have beenstudied this subject for almost two decades. While clones are investigated from diﬀerent perspectivesthe authors addressed new limitations in code clone studies. Firstly, almost all clone studies havebeen done on statically typed languages. Since the nature of statically and dynamically languagesare diﬀerent, developers might clone code diﬀerently. Secondly, there is no study that comparesthe relationship existing between clone properties and software metrics in diﬀerent languages orapplication domains.Thirdly, a limited number of studies on web applications have included qualitative analysis alongwith quantitative once. Fourthly, few studies compared clone between statically and dynamically27typed languages. Lastly, clone coding studies in dynamic languages do not consider diﬀerent ap-plication domains and in spite of the popularity of Java script, studies on JavaScript clones arelimited.They developed a clone detector speciﬁcally for JavaScript. This tool is inspired by Deckard[DEC], so they can use the same conﬁguration for both Java and JavaScript. Then, they used thefollowing code metrics to compare clones in diﬀerent languages and domains:• Cloning locality• Average and maximum lines of cloned code• Clone coverage• Files associated with clones• Function-level clonesThe results show that diﬀerent features oﬀered by programming languages aﬀect code duplica-tion patterns. For example, as JavaScript has no support for method overloading, the number ofmethod level clone for JavaScript is smaller in comparison to Java. It also reveals that a consid-erable amount of JSweb projects have clones and web developers duplicate code intentionally. Inaddition, clone properties in the same language might not be the same for diﬀerent domains.3.8 JavaScript Errors in theWild: An Empirical Study [JPZ11]The authors of this paper intended to study JavaScript errors in web applications and understandingthe source of these errors. They also plan to ﬁnd design guidelines for developing process.Speciﬁcally, they want to investigate:• Errors in JavaScript applications and ﬁnd common characteristics of these errors among webapplications.• The correlation between the speed of interaction between the user and the rate of JavaScripterrors.• Non-deterministic errors in JavaScript web applications.28• Correlation between using JavaScript static and dynamic features and the number of errors.• Correlation between frameworks in developing JavaScript code for web applications and anumber of errors.JavaScript is the most popular language for developing web application client-side functionali-ties. More than 95 percent of today’s websites contains thousands of lines of JavaScript codes. Inspite of Javascript popularity, there is no study on characterizing errors related to JavaScript in webapplications. Web applications might undergo serious malfunctioning due to errors in JavaScriptcodes.In order to investigate the errors in web applications, the authors create test cases. Each testcase contains ﬁfteen test cases based on interaction with web applications. The cases run withdiﬀerent speed and multiple times on ﬁfty web applications from Alexa 4 Top 100.The results of this empirical study show that:• Almost all JavaScript web applications face with error.• They found these errors mainly fall into four categories: Null Exception, Permission Denied,Syntax Error, and Undeﬁned Symbol.• The speed of interaction aﬀects the number of errors.• Most of JavaScript web applications errors are non-deterministic.• Correlation between frameworks in developing JavaScript code for web applications and anumber of errors.• There is a correlation between some of the dynamic and static features of the languages.• Increasing the number of frameworks increases the number of errors in web applications.This study showed that errors occur in almost all websites with JavaScript client-side code.JavaScript developers need to consider the static and dynamic features that they use in their codeand to avoid the error-prone features. Since some errors happen by changing the speed of theinteraction with the websites, this application should be tested in diﬀerent interaction speed.4http://www.alexa.com293.9 JavaScript: The Used Parts [GHWB14]The authors of the paper believe that JavaScript language designers change the language featureswithout knowing how developers apply these features. So, ﬁnding the most used part of the languageto help language designers, tool builders, browser vendors, and researchers is the main concern ofthis paper. This paper also investigates the reason of choosing some features of the language bythe developers. Finally, it shows that how developers adopt new added features and problem pronefeatures.Websites ranked on the Alexa are popular but they cannot be a comprehensive representationof all JavaScript codes in all web applications. So in this paper, they gather a diverse corpus ofsource codes to include diﬀerent developers code from diﬀerent applications and backgrounds. Theycollect more than a million unique scripts that fall into ﬁve categories: Node.js applications, Firefoxadd-ons, Alexa pages, browsed pages(by using Win Web Crawler), and JS libraries.They used a combination of static and dynamic analysis to collect information from the scripts.They instrumented Spider Monkey and it is used for both static and dynamic analysis of browsedand Alexa pages and JS libraries. Node.js applications were analyzed with a instrumented V8engine. Firefox add-ons were the only ones that is analyzed manually.The presented results show that:• Developers tend to apply some problematic features of the language like for ... in and blocklevel declarations (readability of the code is one of the reason that some developers tend todo that).• There are some misunderstanding and browser support that prevents developers to use someof the new language features. For example, the strict mode is only used one percent in thecorpus.• Node.js developers try to beneﬁt from object-oriented features of JavaScript while functionalprogramming is more popular in web applications.30Chapter 4ApproachThe process of analyzing JavaScript source code and extracting sophisticated structures (i.e., classemulations, namespaces, and module patterns) requires more than just a source code parser or anAbstract Syntax Tree (AST) visitor.JSDeodorant is a tool developed at Concordia University to analyze JavaScript source codeand it employs the best practices learned by a former tool JDeodorant developed and designed inConcordia Software Refactoring Lab as Java Refactoring recommendation tool [FTC07] [TCC08].JSDeodorant involves a multi-step analysis to create its own abstraction, which makes it mucheasier to perform diﬀerent software analysis techniques (e.g., control and data ﬂow analysis).The overall view of our approach for detecting function constructors in JavaScript is illustratedin Figure 14.In the following, each of the steps is discussed in detail.4.1 Step 1: Parsing JavaScript Files and Building ModelIn the ﬁrst step, JSDeodorant uses the Google Closure Compiler [cloa] to parse and extract ASTsof JavaScript ﬁles of the given project. We use the Closure Compiler tool as it is a well establishedproject on GitHub with a large community of developers to maintain and support it (179 contrib-utors, 61 releases since 2009). As it is shown in Figure 14, the input is a set of JavaScript ﬁles (atleast one JavaScript ﬁle), which are parsed to obtain their ASTs.31Post-processing2Enhanced ModelSource Element JSModuleAbstractStatementSimpleStatement CompositeStatementSource Element JSModuleAbstractStatementSimpleStatement CompositeStatementSource Element JSModuleAbstractStatementSimpleStatement CompositeStatementObject CreationBinding3Source Element JSModuleAbstractStatementSimpleStatement CompositeStatementHierarchical Model4InferencingJavaScript FilesParsing1Building ModelASTs/** * Read a quoted field from input. * @return {string} The field, as a string. */function readQuotedField() { // We've already consumed the first quote by the time we get here. var start = index; var end = null; for (var token = nextToken(); token != EOF; token = nextToken()) { if (token == '"') { end = index - 1; token = nextToken(); // Two double quotes in a row. Keep scanning. if (token == '"') { end = null; continue; }Unresolvedconstructor invocations Resolvedconstructor invocations Never-invokedfunction constructorsFigure 14: Overview of the Proposed ApproachJSDeodorant then traverses the generated ASTs to build a hierarchical abstract model, whichprovides a higher level abstraction than AST, by capturing the nesting structure of code at thestatement level.4.1.1 Hierarchical ModelWe are using the Composite design pattern to eliminate the complexity of distinguishing betweena leaf node and predicate node (if, for, while, etc.). The beneﬁts of the composite model is that,it can treat complex and primitive objects uniformly, and thus it is possible to manipulate a singleinstance of the object in the same way as it is to manipulate a group of them. The structure of asimple composite is shown in Figure 15.JSDeodorant has a hierarchical data structure keeping elements including statements that areimportant components of the source code’s semantics, where changing those statements would likelyresult in diﬀerent execution behaviors. This means that we are not speciﬁcally interested in trivialstatements such as a = a + b, however we keep them in a hierarchical model and then we canretrieve them when it is necessary for our source code analysis purpose.A list of important elements that we are keeping in our hierarchical model is as follows:32Figure 15: Composite Design Pattern• Creations (i.e.,new foo())• Function invocations (i.e.,bar())• Function declarations (i.e.,function baz() { ... })• Object literals (i.e.,var obj = myVar :20, myFunction : function() { ... } )• Assignment statements (i.e.,a = b;)• Variable declarations (i.e., var a = b;)Capturing above expressions and statements is achieved by our abstraction model and is only im-plemented in AbstractFunctionFragment class which is an abstract class where AbstractExpressionand AbstractStatement are inherited from.When we are creating an instance of AbstractExpression or AbstractStatement, in the constructorof these two classes there are various method invocations (these methods belong to parent class,which is AbstractFunctionFragment) to test, extract and store necessary information (detailed listof elements listed above).During the construction of our model, we create a Program object to represent the program(at ﬁle level) which we are going to analyze. A Program holds a list of SourceElement objects33that can be either AbstractStatement or FunctionDeclaration. Class Program implements theSourceContainer interface, which is the representation of a container. Other classes that imple-ments SourceContainer are CompositeStatement, FunctionDeclarationExpression and ObjectLit-eralExpression since they can contain expressions or statements.Figure 16: An Overview of JSDeodorant ArchitectureAbstractStatement and AbstractExpression classes are representing AST nodes that can bechildren of a composite structure.Figure 16 shows the relationships between Program, CompositeStatement and AbstractStatementclasses. It should be noted that at one higher level of abstraction, there is a class named “module”which contains a program and a list of other modules as dependencies. For example if the codecontains a require statement, to include another JavaScript ﬁle, then the analyzed version of thatmodule (means the parsed and abstracted model of that ﬁle) will be added as a dependency.JavaScript programs can have statements and function declarations in the root. This is diﬀerentfrom object-oriented programming languages, in which programs have to start with a Class as theroot element of source code.For this reason we modeled the program which ought to have two kinds of source elements.The ﬁrst one is function declarations, the most common way to achieve modularity in JavaScriptprograms.34The other source element that can be in the root of program is an AbstractStatement. A listof these source elements is kept in Program class in our model for future analysis.We have a utility class to extract expressions or statements from a source container at anynesting level. To be able to extract the desired information we need a visitor to check every elementtype of the AST. Class FunctionDeclaration represents the structure of a function node in theAST. The hierarchy of composite statements is also shown in Figure 16. A composite statementcan be a TryStatement, a FunctionDeclarationStatement or a LabelledStatement.For example, for a for block (i.e., a composite statement that contains other composite orsimple statements), the model includes only high-level information about the for loop statement(but JSDeodorant does not have corresponding For class in our model, because it is not importantfor our analysis purpose) and the nested statements, which is necessary for detecting patterns weare looking for.4.2 Step 2: Post-processingOnce the model is built, JSDeodorant performs a post-processing with the objective of identifyingﬁle dependencies, which results in an enhanced model with these dependencies resolved.The reason for post-processing is that we have to query the existing model for expressions thatare speciﬁc to the import/export mechanism depending on the chosen module system. Otherwise,we have to deal with low-level AST nodes (i.e., visit all expressions containing binary operatorwhere the right operand is require function call, and the left operand is a variable declaration andthe operator is equal operator).Due to our abstract model, we can query all assignment expressions in the post-processing phasewhere the assignment’s right operand is a function call with the identiﬁer require. This is muchmore convenient than dealing directly with AST nodes.Moreover, when we ﬁnd a require function call, we have to resolve its argument as a path toanother module, and in that module, we have to ﬁnd the appropriate exports or module.exports tobe able to match these two modules mutually.Our model is built upon the CommonJS module system, as it is one of the most popular APIsused by developers. The Closure Library Modules is also supported.However, our approach to identify ﬁle dependencies is generic enough that it can be easily35extended to capture other dependency patterns, such as AMD.For dependencies that cannot be resolved with the require/exports pattern, JSDeodorant triesto resolve them by reading the package.json ﬁle which is speciﬁed by the CommonJS standard,and contains information about module’s main ﬁle, and dependencies to other modules. This way,JSDeodorant tries all the possible approaches to make sure that the dependencies between ﬁles areresolved in a proper way.In terms of design and implementation, it requires for each module system, a class is beingcreated and make it to inherit from PackageExporter and PackageImporter interfaces for extractingexport and import statements correspondingly.4.3 Step 3: Binding Object CreationsNext, JSDeodorant performs a lightweight data-ﬂow analysis on the enhanced model, produced inthe previous step. The objective of this step is to bind each class instance creation to a functionconstructor, which results into two disjoint sets of resolved and unresolved function constructorinvocations. JSDeodorant traverses the model, and in each JavaScript module, it analyzes theidentiﬁer name in the instance creation expressions (i.e., expressions using the new operator). Eachidentiﬁer name can be either a simple or composite name.4.3.1 Simple Name Identiﬁer:For simple identiﬁer names (e.g., MockWindow in new MockWindow()), JSDeodorant ﬁrst searchesthe current block to ﬁnd the function declaration, where the function name matches the constructorinvocation name. If no such declaration is found, it recursively searches the parent blocks until itﬁnds a matching declaration, and marks the corresponding constructor invocation as resolved. Ifwe reach the root of the JavaScript module and we are unable to identify a declaration, we searcha list of predeﬁned JavaScript functions for a match [javb].The reason for consulting the predeﬁned list after our internal search is that, it is possible toredeﬁne JavaScript native objects, although it’s a risky practice [Stad] [per] [java].364.3.2 Composite Name Identiﬁer:Resolving composite identiﬁers addresses the cases where the function constructor is deﬁned withina nested namespace or an object literal, internally or externally. That is, the declaration of the func-tion constructor may be within the same ﬁle or elsewhere. Examples of composite names are given inFigures 9 and 10 where the function constructor is deﬁned in a namespace (namespace.PublicClass),and Figure 11-A (line 2) where the class is deﬁned in another module (Writer.write).JSDeodorant ﬁrst splits the identiﬁer name into its tokens (e.g., for namespace.PublicClass) and then searches the current block for the leftmost token (i.e.,namespace). Statements of interest are variable assignments and property names in object liter-als. If JSDeodorant ﬁnds a match (line 1 in Figure 9-A), it tries to match the next token (i.e.,PublicClass) within the already matched context (e.g., lines 1-7 in Figure 9-A) and this processcontinues until all tokens are matched.4.4 Step 4: Inferring Function ConstructorsIf a constructor invocation cannot be resolved to a function constructor in the previous step, JS-Deodorant attempts to resolve it by using an inference mechanism.JSDeodorant analyzes the body and prototype objects of functions; if a function deﬁnes prop-erties or methods (either directly or through the prototype object), it is considered as a functionconstructor.Some of these identiﬁed function constructors can be matched with the unresolved constructorinvocations from the previous step. The rest essentially corresponds to the function constructorsthat are nowhere invoked (instantiated) in the code.This technique is useful for those JavaScript projects that are designed and built for speciﬁcpurposes which they do not have instantiation of the code along with the deﬁnition such as librariesor frameworks.The detailed algorithm of our technique is written in a pseudo code style in Algorithm 1.37Algorithm 1 Function constructor detection algorithm1: cont list=loadListofConstrucotrs()2: for fd in functionDeclarations do3: if ! (fd in cont list) then4: if HASPROPERTY(fd) OR HASMETHOD(fd) thencont list.add(fd)5: end if6: end if7: end for8: procedure hasProperty(fd)9: assignments=fd.getAllAssignment()10: for a in assignments do11: if a.getLHS() instanceof FieldAccess AND !(a.getRHS() instanceof FunctionDeclaration) thenreturn TRUE12: end if13: end for14: end procedure15: procedure hasMethod(fd)16: assignments=fd.getAllAssignment()17: parent= fd.getParent()18: for a in assignments do19: if a.getLHS() instanceof FieldAccess AND a.getRHS() instanceof FunctionDeclaration thenreturn TRUE20: end if21: end for22: parent assignments=parent.getAllAssignment()23: for pa in parent assignments do24: if Prototypeof(fd).contains(pa.getLHS()) AND pa.getLHS() instanceof FunctionDeclaration thenreturn TRUE25: end if26: end for27: end procedure38Chapter 5Evaluation of AccuracyWe designed an empirical study, with the goal of answering the following research questions:• Precision and Recall: What is the performance of JSDeodorant in detecting functionconstructors? The goal is to assess how accurate and complete is the sample of detectedfunction constructors. We measure precision and recall to answer this research question.• Comparison with the state-of-the-art tool: Does JSDeodorant outperform the state-of-the-art tool in terms of precision and recall? The goal is to compare the eﬃcacy of JSDeodorantand JSClassFinder in terms of precision and recall on the same dataset.5.1 OracleTo measure the precision and recall of JSDeodorant and JSClassFinder, we need an oracle offunction constructor declarations. We used three open-source JavaScript projects to automaticallybuild the oracle (i.e., to avoid any bias). There are two ways to achieve this:Using JSDoc annotations: JavaScript developers can annotate function constructors using JS-Doc’s @constructor annotation [JSDb]. In this case, function constructors can be automati-cally found by simply parsing JSDoc comments. We used closure-library (a large library usedin Google products, such as Gmail and Maps), as it is JSDoc-annotated project. Unfortu-nately, JSClassFinder threw Out of Memory error for closure-library, so we had to manually39execute it folder-by-folder.Using transpiled code: TypeScript [typ] and CoﬀeeScript [cof] are supersets of JavaScript thatadd the missing features (e.g., syntax for class declaration) to JavaScript. The code written intheir syntax is transpiled to vanilla JavaScript. By parsing and extracting class declarations inTypeScript/CoﬀeeScript programs, class declarations can be found. The corresponding func-tion constructors, resulting from transpiling TypeScript/CoﬀeeScript code, are then added tothe oracle. We selected two GitHub-trending projects, doppio and atom, respectively writtenin TypeScript and CoﬀeeScript.These projects are medium-sized, to prevent JSClassFinder from crashing.In Table 1, we have reported the main characteristics of the programs used to build the oracle.Table 1: Characteristics of the Analyzed Programs.Project Version Size (KLOC) #JS Files #Functionsclosure-library 20160315 605 1,502 23535doppio rev:7229e7d 17.7 47 1977atom v1.7.0-beta5 34 116 3175This section reports the results of our quantitative and qualitative analysis of the three programswith respect to the two research questions formulated above.5.2 Precision and RecallTo ﬁnd out about the eﬃcacy of these two tools, we calculated the precision and recall using thefollowing formulas. TP stands for True Positive: is a function that is detected by the tool as functionconstructor and is in the oracle too. FP stands for False Positive: is a function that is detectedby the tool as function constructor, but it is not in the oracle. FN stands for False Negative: is afunction that is NOT detected by the tool as function constructor, but it is in the oracle) :Precision =|TP ||TP |+ |FP | and Recall =|TP ||TP |+ |FN |Table 2 illustrates the results of JSDeodorant .As it is observed, JSDeodorant can achieve a high precision and recall, for all three analyzedprojects.40Table 2: JSDeodorant Precision and Recall.ProgramIdentiﬁedTP FP FN Precision Recallfunction constructorsclosure-library 1008 907 101 39 90% 96%doppio 154 153 1 1 99% 99%atom 106 101 5 1 95% 99%We further qualitatively analyzed false positives and false negatives. For closure-library, 18 ofthe false positives are functions that are annotated with @interface. JSDeodorant identiﬁed theseas function constructors, since methods (with empty body) were added to their prototype.Other false positives in closure-library (83 cases) included functions deﬁned in test ﬁles, withoutany JSDoc annotation. We manually inspected these functions and marked them as true positive(TP) or false positive (FP). The decision to label the detected functions as TP or FP was based onthe use and deﬁnition of the functions.That is, if the function was invoked as a constructor (with the new operator), or at least oneproperty or method (non-empty body) was deﬁned in its body (or added to its prototype), it waslabeled as TP. The ﬁnal label was decided by unanimous voting, and the third vote was sought incase of conﬂict. Out of 83 cases, 82 were labeled as TP, leaving only one case as FP.As explained in Section 4, JSDeodorant identiﬁes functions that have at least one property, ormethod as function constructors. Moreover, those constructor invocations that JSDeodorant bindsto a valid declaration are also identiﬁed as function constructors. The false negatives were thosecases where the body of the function did not match our deﬁnition of function constructor, and theywere not instantiated.Our investigation showed that our approach is unable to identify function constructors that arenot invoked, and at the same time, do not contain any property or method (i.e., false negatives).Here we brieﬂy discuss ways to improve our technique.Analyzing function’s use: JSDeodorant fails to identify two sets of non-invoked functionconstructors: 1) empty function constructors, and 2) function constructors with no method orproperty. We plan to analyze the use of these functions to improve our detection technique. Forexample, if a function is an operand of instanceof, or an argument of Object.create() func-tion, it is most probably a function constructor. Another way is to infer inheritance relationshipsbetween objects. For example, Figure 17 shows an example in closure-library where the function41goog.net.WebChannel.MessageEvent = function() { goog.net.WebChannel.MessageEvent.base( this, 'constructor', goog.net.WebChannel.EventType.MESSAGE);};goog.inherits(goog.net.WebChannel.MessageEvent, goog.events.Event);179180181182183Figure 17: Example of a Function Constructor JSDeodorant Failed to Identifyconstructor is not invoked in the program and it is not possible to infer from its body that thegoog.net.WebChannel.MessageEvent is a function constructor. However, we could infer from thestatement at line 183 that the function is involved in an extends relation with another class andthus it is a function constructor.Distinguishing classes from interfaces: JSDeodorant fails to diﬀerentiate classes and inter-faces. This can be mitigated by checking whether a class contains methods with an empty body,and it is not a superclass of other classes. In such a case, the detected class can be labeled as aninterface.Overall, we found that JSDeodorant achieves high precision (95%) andrecall (98%) on the selected dataset.5.3 Comparison with the state-of-the-art toolWe run JSClassFinder on the same dataset we used for our ﬁrst research question, summa-rizing the results in Table 3. JSClassFinder crashed on two sub-directories of closure-library(/closure/goog/crypt and /closure/goog/i18n), due to invalid input format and out of memoryexceptions, respectively. Thus, we excluded the function constructors (27 cases) in those two sub-directories, to calculate precision and recall in a fair manner. A manual analysis of false positiveswas done similarly to Section 5.2, and out of 42 cases, 41 were labeled as TP. By manually checkingall false negatives were cases where function constructors were not invoked, which is one of themajor limitations of JSClassFinder.To compare the performance of the tools, we enhanced our automatically-built oracle by addingthose cases labeled as TP during our qualitative analysis. Moreover, to do a fair comparison, weremoved function constructors belonging to sub-directories in which JSClassFinder crashed fromthe oracle and the results of JSDeodorant .42Table 3: JSClassFinder Results of Detection.Project OracleIdentiﬁedTP FP FN Precision Recallfunction constructorsclosure-library 919† 769 727 42 192 94% 79%doppio 154 23 22 1 131 96% 14%atom 102 95 95 0 7 100% 93%† Function constructors in two sub-directories of closure-library are removed from the oracle.In Table 4, the accuracy measures for both tools are reported. As it is observed, JSClassFinderperformed well on both accuracy measures for atom. This is because all function constructors wereinvoked in atom, and thus, JSClassFinder identiﬁed them all.However in the other two projects, it fails to identify function constructors that are not invoked.Table 4: Accuracy Measures for Both ToolsProjectJSClassFinder JSDeodorantPrecision Recall Precision Recallclosure-library 99% 76% 98% 96%doppio 96% 14% 99% 99%atom 100% 93% 95% 99%Average 98% 61% 97% 98%Here we want to report the main problems we faced when working with JSClassFinder:• Running JSClassFinder on JavaScript programs is not straightforward. This tool requires toﬁrst manually extract ASTs from JavaScript ﬁles using a third-party JavaScript parser andstore it in JSON 1 format. The JSON ﬁles are then used as an input to JSClassFinder. Thisextra step makes JSClassFinder less usable and diﬃcult to integrate in Integrated Develop-ment Environments (IDEs).• JSClassFinder is matching new expressions with function names “blindly”. Even if you havetwo independent ﬁles that are not connected using CommonsJS or AMD import/export state-ments, the tool will still search for a matching between these two ﬁles. We think the processof ﬁnding function constructor should be more sophisticated than a simple name or AST nodematching and that’s why we choose to implement CommonJS and ClosureLibrary styles forconnecting ﬁles that are linked to each other.1JavaScript Object Notation43function ArrayIterator(array) { this.array_ = array; this.current_ = 0;}goog.inherits(ArrayIterator, goog.iter.Iterator);12345Figure 18: Example of a Function in the Test Code That Was Not Annotated, but Added to theOracle as a Function Constructor. Overall, we found that both tools have very high precision on average,while JSDeodorant greatly outperforms JSClassFinder with respect torecall on the selected dataset.5.4 Threats to ValidityConstruct validity: We only addressed module dependencies that comply with CommonJS andClosure-Library style; thus, we need to replicate this study with JavaScript projects that use othermodule systems, e.g., AMD. The post-processing step can be easily extended to support othermodule systems. Since the core of the approach does not depend on any module system, we areconﬁdent that JSDeodorant will perform similarly well.In addition, our lightweight data-ﬂow analysis only supports simple name aliasing, and thus,more complex cases of name aliasing (e.g., variable name in a return of a function call) is left asfuture work.In the manual investigation phase for augmenting the oracle the independent evaluators mightboth misinterpreted the intention of the developer who wrote the code. For example, in ClosureLibrary project, we found a function located in closure-library-v20160315closuregoogiter iter test.jsline 23, which does not contain any @Constructor annotation. Figure 18 shows the piece of codethat is considered as a class based on the votes of two independent investigators. It might bepossible that the developer’s intention is not to use this function as a function constructor, buttaking into account the inherits call that follows, it seems that ArrayIterator extends Iterator byadding to additional ﬁelds.44External validity:While these preliminary results of analyzing three projects from diﬀerent domains show thatJSDeodorant detects function constructors with a high accuracy compare to JSClassFinder tool,and the result of analysis on three JavaScript projects conﬁrms existence of classes in diﬀerentJavaScript projects, we acknowledge the need for examining a wider range of JavaScript projects.To enable the reproduction of our study, the oracle along with the detected classes for bothtools are available on-line [jsda].45Chapter 6Empirical StudyIn Chapter 5 we evaluated the eﬃcacy of JSDeodorant in detecting function constructors in JavaScriptprograms. JSDeodorant achieves relatively high precision and recall. To gain a better understand-ing how JavaScript developers adopt classes in their programs, we conduct and empirical studyby running JSDeodorant against a dataset of JavaScript projects from diﬀerent categories. Thischapter presents the targeted JavaScript programs, the study setup and the results of the study.6.1 Study Setup and ResultsWe collect a dataset consisting of three major categories: NodeJS projects, websites and libraries.We think breaking down JavaScript projects into these three categories shows the diﬀerence ofthe adoption of class usage among three major domain that JavaScript is used. Moreover otherresearchers also propose this categorization based on the domain of programs in previous works[GMB15] [CRK16].For NodeJS projects, our selection was based on the NPMJS website 1 which ranks Nodepackages by the number of downloads. For the JavaScript ﬁles on the Websites, we ran Crawljax[MvDL12], a headless crawling engine, to collect JavaScript ﬁles. Crawljax emulates the behaviourof users by ﬁring user events, e.g., clicking on elements in web pages, while capturing JavaScriptﬁles in diﬀerent stages. Finally, for libraries, we collected seven popular JavaScript libraries, based1www.npmjs.com/46on the number of stars of the corresponding repositories on GitHub.Note that, for libraries and NodeJS projects, we excluded all the miniﬁed ﬁles (i.e., ﬁles thatwere miniﬁed using speciﬁc programs that decrease ﬁle size by removing whitespace characters,renaming variables, etc.), to avoid the detection of duplicated classes in the original and miniﬁedversion. We also choose to run JSDeodorant against Silva et.al [SRV+15] dataset. All the projectsthey collected are considered as libraries, thus we put them in the libraries category.Table 5, 6 and 7 shows the characteristics of the projects under analysis, including their projectname, analyzed version, size (in KLOC), number of ﬁles, number of functions along with the numberof identiﬁed function constructors in diﬀerent JavaScript programs. The last two columns shows thenumber how many number of methods deﬁned within the body (Method Inside - MI) of functionconstructor and the number of methods assigned to the prototype object (Method Outside - MO).6.2 DiscussionAs it is shown in Table 5, there are 25 programs with no classes which forms 52% of all nodeprojects. It is shown that less.js has a relatively high number of classes compared to other projectswith total of 77 classes. Looking further, the number of methods assigned to the prototype object(MO) for less.js is 55 compared to 22 methods deﬁned inside the body of function constructors.We think less.js adopts a good level of OOP and also it follows best practices promoted by thecommunity such as deﬁning methods to the prototype [PRO].In Table 6 it is shown that only 10% of the websites do not have any usage of classes.. There isone website (facebook.com) with a relatively high number of classes (312).Interestingly Table 7 shows that 10% of all examined libraries have no usage of classes..As it can be observed, from an eyeball analysis of the results there is a diﬀerence between thenumber of classes for projects within diﬀerent categories. We observe that NodeJS projects havefewer number of classes compared to websites.To statistically conﬁrm this observation, we ﬁrst normalize the number of classes with thenumber of ﬁles for each of the projects, in order to conduct a fair comparison among the categories.As we need to select an appropriate statistical test for the comparison, we ﬁrst used the Shapiro-Walk test to assess whether the distribution of the data for these normalized values is normal or47not. The results of the test rejected the null hypothesis that the data is normally distributed (p-value <2.179e-10 , 1.88e-08 and 7.973e-12 respectively for NodeJS projects, websites and libraries).Thus, we use the Wilcoxon rank sum test (also called the MannWhitney U test), a non-parametricstatistical hypothesis test for which the data under test does not need to be normally distributed,to ﬁnd out if there is any statistically signiﬁcant diﬀerence between the number of classes in thesecategories. The results show that NodeJS projects have fewer classes compared to website projects(p-value <6.78e-07). We cannot conclude if there is a diﬀerence between libraries and websites,since the p-value is 0.5034. Moreover, we conﬁrm that NodeJS projects have less number of classescompared to libraries (p-value <1.963e-07).ﬃﬁﬂWhen comparing the number of classes between the categories, we ob-served NodeJS projects have fewer classes compared to websites andlibraries but we cannot compare the level of class adoption between com-paring libraries and websites.We conjecture that NodeJS projects have adopted classes to a lesser extent, because developersdominantly follow a diﬀerent reuse approach when developing NodeJS applications. These appli-cations are mainly constructed by importing and connecting small pieces of code from externalpackages, which are mostly written by other developers. In this case, as the code base is rathersmall, and the imported code is already organized using some packaging system (and therefore,only exposing what is required by the clients), the probability of name collisions would be low,making the use of classes an overkill for the maintainability. Moreover, the asynchronous (i.e.,non-blocking) nature and event-driven architecture of NodeJS make it a great runtime environmentfor speciﬁc types of software which, instinctively, might not need classes for encapsulating data andbehaviour.On the other hand, we observe that websites are using more classes, and this can bear variousreasons. One possible reason is that name collision is more probable in websites JavaScript ﬁles.This is because web pages usually need to import several JavaScript ﬁles. These ﬁles can beimported, in the required order, using the

JavaScript Prototypes, Objects and Classes

Abstract

Extracted data

JavaScript Prototypes, Objects and Classes

Abstract

Extracted data

Topics

Related items

Topics

Related items