Does the discipline of preprocessor annotations matter?

Abstract

The C preprocessor ( CPP ) is a simple and language-independent tool, widely used to implement variable software systems using conditional compilation (i.e., by including or excluding annotated code). Although CPP provides powerful means to express variability, it has been criticized for allowing arbitrary annotations that break the underlying structure of the source code. We distinguish between disciplined annotations, which align with the structure of the source code, and undisciplined annotations, which do not. Several studies suggest that especially the latter type of annotations makes it hard to (automatically) analyze the code. However, little is known about whether the type of annotations has an effect on program comprehension. We address this issue by means of a controlled experiment with human subjects. We designed similar tasks for both, disciplined and undisciplined annotations, to measure program comprehension. Then, we measured the performance of the subjects regarding correctness and response time for solving the tasks. Our results suggest that there are no differences between disciplined and undisciplined annotations from a program-comprehension perspective. Nevertheless, we observed that finding and correcting errors is a time-consuming and tedious task in the presence of preprocessor annotations.

Composing annotations without regret? Practical experiences using FeatureC

“…We are able to avoid some grammatical changes through the source‐code discipline. () In C , only annotations in the following: (1) entire functions, (2) type definitions, (3) entire statements, or (4) elements inside type definitions are considered to be disciplined . Still, it is not possible to solve all problems this way.…”

“…() However, there is still ongoing discussion whether annotations make it more difficult to develop systems or not. () Several researchers suggest to restrict the power of conditional inclusion, leading to a more disciplined usage of preprocessors . In addition, to overcome the limitations regarding feature traceability and physical separation of concerns, composition‐based approaches were proposed.…”

Do #ifdefs influence the occurrence of vulnerabilities? an empirical study of the linux kernel

“…Based on existing work that suggests that the presence of #ifdefs in source code complicates maintenance tasks and requires additional effort from developers when trying to understand variable code dependencies [21,24,36], we aim at investigating the influence that code configurability has on the occurrence of vulnerabilities.…”

“…Preprocessor directives (#ifdef statements) are frequently used as a mechanism to support code variability and thereby permit the diversification of software products. However, it is known that the presence of #ifdefs in source code complicates maintenance tasks and requires additional effort from developers when trying to understand feature code dependencies [21,22,36].…”

Preprocessor-based variability in open-source and industrial software systems: An empirical study

“…Many researchers have stated that the use of cpp is likely to result in errorprone code that is difficult to understand and maintain [Spencer and Collyer, 1992;Favre, 1997;Lohmann et al, 2006;Schulze et al, 2013]. However, especially in the context of highly-configurable systems and software product lines, the preprocessor is still the standard tool [Jepsen and Beuche, 2009;Ganesan et al, 2009], and several researchers work on improved versions that avoid many of the pitfalls [Kästner et al, 2008b;Favre, 1997;Erwig and Walkingshaw, 2011;McCloskey and Brewer, 2005;Weise and Crew, 1993], on tools to migrate to alternative implementations [Adams et al, 2009;Kumar et al, 2012;Tomassetti and Ratiu, 2013;McCloskey and Brewer, 2005], and on tools to cope with existing cpp implementations [Vo and Chen, 1992;Krone and Snelting, 1994;Feigenspan et al, 2013;Kullbach and Riediger, 2001;Singh et al, 2007;Ribeiro et al, 2011].…”