# Quality Properties of Execution Tracing, an Empirical Study
## 2 Related Works  
In this section, account is given of the works related to the present study. For discovering the related works, traditional literature review was applied. In addition, the references of the works identified in the scope of the review were also analysed to discover further research on the area. As stressed in Section 1, the related works explicitly state the need for overall guidelines for preparing execution tracing; moreover, they confirm the absence of such directives [16; 17; 18; 19; 20]. [PERSON] and [PERSON] analyse the reasons for log code changes and articulate six antipatterns for logging but do not form overall guidelines [18; 19]. The majority of the publications with regard to the problem they address can be classified in three groups: (1) where to insert log statements in the source code [23; 24; 25; 26; 27; 28; 13; 20], (2) what to log to provide sufficient information for failure analysis [13; 17; 27; 29], and (3) how to log [13; 19; 27]. Tool support for selecting the appropriate places in the source code for inserting log statements consistently or for achieving optimal performance by the trade-off in the amount of information logged and the speed of execution usually involve more than one group mentioned above [13; 17; 25; 26; 27; 28; 29]. [PERSON] et al. investigate where to insert log statements in the code what are the benefits and costs; moreover, they list the tools for supporting the automatic insertion of log messages also from performance monitoring aspects [23]. [PERSON] et al. deal with the questions where to log and what amount of information to log so that it would not be too little and too much. [PERSON] et al. construct a tool based on machine learning that processes changes between the versions in source code repositories and make suggestions where to insert log statements [25]. [PERSON] and [PERSON] in [15] and [PERSON] et al. in [14] investigate whether error reports with logs are resolved quicker than those without logs. In addition, [PERSON] and [PERSON] define five different anti-patterns in the logging code and develop a tool to detect them [19]:  
**Nullable object:**: While constructing the log message, an object that should deliver data to the log message is also null, which causes NullPointerException. Resolution: Checking the objects contributing to the log messages. **Explicit cast:**: An explicit cast can throw exception during the runtime conversion. Resolution: Removing the explicit cast. **Wrong severity level in the log message:**: Wrong severity level can cause serious overhead in the log data or lack of information in the necessary analysis. Resolution: Using the appropriate severity level. **Logging code smells:**: Retrieving the necessary information might result in long logging code with chained method calls like _a.b.c.d.getSmg()_. This causes maintenance overhead and deteriorates understanding. Resolution: Using a local variable or a method to provide the necessary information to the logging code. **Malformed output:**: The output cannot be read by humans. Resolution: Formatting it appropriately. The Apache Common Best Practices document describes points to consider for creating consistent severity levels in the logging code statements but the description does not contain overall guidelines for logging [30]. [PERSON] et al. investigated logging practices in 144 open-source Android applications and drew the conclusion that mobile applications deviate from desktop and server applications [31]. They explicitly state that the usefulness of logging depends on the quality of logs and support is needed for logging decisions with respect to (1) severity level, (2) logging code location, (3) text in the log message, and (4) when to update the log statements [31]. [PERSON] et al. analysed log related issues in Jira reports and in the corresponding code changes as missing or outdated information can have considerable impact causing extra overhead with the analysis carried out by developers or wrong decisions made by system operators [17]. [PERSON] et al.