In this blog post we present some ideas that one can consider before conducting a qualitative survey to evaluate new software engineering tools and systems. These tips derive from our own surveys conducted on Android developers as part of my research in software engineering.
In software engineering the “big data” catchphrase refers to in-homogeneous large-scale data that can stem from all software development cycles. Such data can be: source code, software bugs and errors, system logs, commits, issues from backtracking systems, discussion threads from consulting sites (e.g. stackoverflow.com), emails from mailing-lists, as well as developers’ demographic data and characteristics and user requirements and reviews. Software engineering can benefit from the aforementioned data in many ways, but there are several challenges regarding the handling of such data.
Given that usually the compiler does not complain about the coding style of a program (i.e. missing white spaces, indentation, long lines of code, name conventions, and comments), developers care only for the functionality of their programs and not for the maintainability. However, this can be harmful for the understanding and maintenance of modern software systems. This post discusses the importance of writing programs based on specific coding guidelines.
Static analysis is a method that one can use in order to analyze, understand, and assess the quality of a program. The main strength of static analysis is the pinpointing of coding errors without the execution of a program. In this blog post, we discuss how static analysis can contribute to the evaluation of the existing exceptions of a program and how static analysis can help in the prediction of possibly thrown exceptions by a program.
The execution of a program can suddenly terminate for several reasons. To prevent unexpected program behaviors, developers can include error handling mechanisms in their programs. Specifically, in Java, developers can use two types of exceptions: checked and unchecked. Checked exceptions (IOException, DataFormatException, ParseException, SQLExceptions, etc.) are always caught on compile time, whereas unchecked exceptions (OutOfMemoryError, ArithmeticException, NullPointerException, IllegalArgumentException, IllegalStateException, etc.) can occur on runtime and lead a program to an unexpected termination (crash)—if there is no prevention mechanism in the source code to caught the exception. However, there is a debate regarding the use of the unchecked exceptions in the source code (see Unchecked Exceptions — The Controversy, in the Java documentation).