MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Techniques for JavaScript debugging BACHELOR THESIS Jakub Jurových Brno, 2014 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Jakub Jurových Advisor: RNDr. Radek Ošlejšek, Ph.D. ii Acknowledgement I would like to thank my supervisor RNDr. Radek Ošlejšek, Ph.D. I am grateful for his help and insights that helped me to write this thesis. iii Abstract It is very difficult to understand and debug code, especially if it was written in one of the dynamically typed languages like JavaScript. As a result, programmers spend a lot of time debugging their ap- plications. This thesis presents Recognizer, a tool for faster debug- ging, along with its JavaScript implementation. Recognizer aims to improve productivity of programmers by automatically logging all variables and expressions in a runtime. The data obtained from the logging are then transferred to a code editor and visualised in real time by semantically highlighting the code. The code’s colour high- lighting is based on real data instead of a static syntax analysis. De- bugging with real-time semantic highlighting is being compared to traditional debugging techniques that usually involve step debug- gers and log statements. iv Keywords semantic highlighting, code understanding, programming, debug- ging, code visualisation v Contents 1 Introduction ............................1 1.1 Seeing the Data . .1 1.2 Information Foraging Theory . .2 1.3 Recognizer . .3 1.4 Organisation of This Thesis . .4 2 Current State of Debugging and Related Work .......5 2.1 Principles of Debugging . .5 2.2 Step Debuggers . .6 2.3 Log Statements . .8 2.4 Always-on Debugging . .9 2.5 Interactive Programming . 12 3 Recognizer ............................. 14 3.1 Implementation Decisions . 14 3.2 Debugging with Recognizer . 15 3.2.1 Semantic Highlighting . 15 3.2.2 Variable Inspection . 17 3.2.3 Counting Function Calls . 18 3.2.4 Instrumentation Heuristics . 20 3.3 Case Studies . 20 3.3.1 Case Study 1: Code Understanding . 21 3.3.2 Case Study 2: Discovering Bugs . 23 3.4 Implementation Details . 24 3.4.1 Brackets . 25 3.4.2 Remote Debugging Protocol . 25 3.4.3 Code Instrumentation . 25 Identifiers . 26 Member Expressions . 27 Call Expressions . 28 Function Entries . 29 3.4.4 Runtime Tracer Code . 29 3.4.5 Serving Instrumented Files . 30 3.4.6 Retrieving Values . 30 3.5 Current Problems and Limitations . 31 3.5.1 Browser Support . 31 3.5.2 Performance . 32 vi 3.5.3 Languages Compiled to JavaScript . 34 3.5.4 Error Handling . 34 3.5.5 Integration with Development Workflows . 35 3.6 Future Development . 35 4 Summary .............................. 37 vii 1 Introduction Programming is difficult. We build extremely complex applications which are difficult to navigate and understand. We cannot see how different parts of a program interact with each other, whether a cer- tain function was even evaluated, or what arguments were passed to it. It is too easy to introduce and too hard to fix a bug in such a system. Code is grouped into modules, classes and objects, but despite all the naming conventions and best practices, we only see the code. No matter how experienced the programmer is, it takes too much time to understand what the code does. We need to read it line by line, imagine how it is evaluated by a computer, keep the state in the head, and hope we didn’t make any mistake along the way. I think we can do better. Reading code line by line is a task for a computer. When we read the code, we should see more than that. We should see what the code means and does. We should see the data hidden behind it [1]. Despite the long history of research in debugging, this problem has not yet been solved [2]. The goals of this thesis are 1 to pro- ¨ vide an overview of existing approaches, 2 design new debugging ¨ © techniques embracing this problem, and 3 develop a working im- ¨© plementation of these techniques. © 1.1 Seeing the Data Bret Victor argues that “The entire purpose of code is to manipulate data, and we never see the data." [3] We see only the final state, not the inter- mediate steps. During development, seeing the intermediate steps is problem- atic. We cannot see how it works. For example, the following code tells us nothing about itself. 1 1. INTRODUCTION 1 person.walk(5); We can see the method walk is being called. It might modify the state in some way, but we don’t know how. We need to read its defini- tion line by line. More importantly, it tells us nothing about the data. What has changed? We can capture the state before and after we call person.walk (amount). 1 console.log(person);//{name:"Joe", walkingDistance: 5} 2 person.walk(5); 3 console.log(person);//{name:"Joe", walkingDistance: 10} The additional log statements helped us understand how the pro- gram works. We can see the data and we can see the change. Now it is easy to understand that person.walk increments walkingDistance by a certain amount without looking at its definition. We can see the behaviour. 1.2 Information Foraging Theory To properly design and evaluate a debugging interface, we need to understand how programmers think. During debugging, programmers spend 35 % of their time by me- chanically navigating the code [4]. Besides losing the visual context on every “jump”, this is a considerable efficiency problem. Switching between files is a relatively huge investment in terms of both time and mental effort. Information foraging theory (IFT) describes how people look up relevant information, follow information paths and determine which paths contain the most relevant information, also known as informa- tion scent. IFT studies how humans are able to efficiently find infor- mation with minimal mental cost. IFT provides a powerful framework for understanding the be- haviour of programmers trying to fix the bug or understand the code. In the context of software debugging, the key terms of IFT can be 2 1. INTRODUCTION defined as follows [5, 6]: • Predator The programmer who is debugging, looking for a source of the bug. • Prey The source of the bug that the programmer wants to fix and all other information needed to achieve that goal. • Information patch Regions containing many information sources. For example, the patch can be a single document or a debug- ger window. The programmer can navigate inside the same patch with little cost. • Information scent Perceived value of information and the cost associated with its obtaining. This is inferred from cues, such as a comment in the source code or an icon in a debugger’s user interface. Based on the personal preference or complexity of the task, pro- grammers use different programming methods. In hypothesis-based debugging, programmers think about the problem as a whole. On the other hand, in scent-based debugging, programmers try to anal- yse the problem bottom-up, closely following the information forag- ing theory [5]. Scent-based programming involves tracing of infor- mation usually by reading the source code or documentation. According to Lawrance et al. [5], programmers use scent-based techniques about 4 times more often than hypothesis-based tech- niques. However, a majority of current debugging tools (presented in Section 2) weren’t designed to support the debugging process based on the information scent. 1.3 Recognizer I designed a new debugging tool, Recognizer, to explore ideas such as semantic highlighting (see Section 3.2.1). Recognizer’s working implementation targets JavaScript and is released under an open-source license. Recognizer can be installed as an extension for Brackets code editor (see Section 3.4.1). Recognizer brings real-time data from the runtime to the pro- grammer in form of semantic code highlighting (see Section 3.2.1) 3 1. INTRODUCTION and inspectable variables (see Section 3.2.2). It aims to solve a com- mon problem of inspecting intermediate values of variables, which is especially troublesome in dynamically typed languages. Addition- ally, each function call is logged and visualised using a simple counter near the function declaration (see Section 3.2.3). This kind of detailed inspection answer many questions the programmers may have dur- ing debugging [7, 8]. Thanks to the real-time updating, programmers are able to eas- ily verify their assumptions about the code: “When I click this button, will this function be evaluated?" Patterns inside the code can be easily identified as well: “These functions have been evaluated the same number of times, they are probably somehow related." With Recognizer it is much easier to understand new code. To answer a question “Which variable stores the value of this input field?" we just need to 1 write something into the input field and 2 skim ¨ ¨ the code, looking for the same value. Compare this to the traditional © © way, where we need to 1 read the code in detail, 2 make assump- ¨ ¨ tions about APIs, 3 make a guess, and finally verify it by 4 setting ¨ © © ¨ a breakpoint and 5 re-running the program. ¨© © © 1.4 Organisation of This Thesis Chapter 2 presents an overview of both state-of-the-art and tradi- tional debugging techniques. I focus on how the discussed tools present runtime data to the programmers and how they help them under- stand the code. The main contribution of this paper, Recognizer, is described in detail in Chapter 3.