Software product lines have gained momentum as an approach to generate many variants of a program, each tailored to a specific use case, from a common code base. We implement variabilityaware parsers for Java and GNU C and demonstrate practicability by parsing the product line MobileMedia and the entire X86 architecture of the Linux kernel with 6065 variable features. Beyond the obvious task of detecting syntax errors, our parser paves the road for further analysis, such as variability-aware type checking. As part of the TypeChef project, we contribute a novel variability-aware parser that can parse unpreprocessed code without heuristics in practicable time. However, current parsing solutions use heuristics, support only a subset of the language, or suffer from exponential explosion. To analyze code with its variability, we need to parse it without preprocessing it. Unfortunately, while being a simply way to implement variability, conditional compilation and lexical macros hinder automatic analysis, even though such analysis would be urgently needed to combat variability-induced complexity. In many projects, lexical preprocessors are used to manage different variants of the project (using conditional compilation) and to define compile-time code transformations (using macros). We integrate these and other findings in a tool called FeatureCommander, which facilitates program comprehension in practice and which can serve as a basis for further research. Additionally, we found that subjects generally favor background colors. Our results demonstrate that background colors have the potential to improve program comprehension, independently of size and programming language of the underlying product. In three controlled experiments with over 70 subjects in total, we evaluate whether and how background colors improve program comprehension in preprocessor-based implementations. Instead, we and others propose to increase the readability of preprocessor directives by using background colors to highlight source code annotated with ifdef directives. There are many voices that suggest to use other implementation techniques instead, but these voices ignore the fact that a transition from preprocessors to other languages and tools is tedious, erroneous, and expensive in practice. However, preprocessor directives have been heavily criticized in academia and even referred to as “#ifdef hell”, because they introduce threats to program comprehension and correctness.
Preprocessor directives are easy to use, and many mature tools are available for practitioners. In practice, software product lines are often implemented with preprocessors. See my discussion on why I built DMS, to enable Life After Parsing.Software-product-line engineering aims at the development of variable and reusable software systems. Ī lesson people keep relearning when building program analysis tools is that parsing is nowhere near enough. PARLANSE (parallel programming language for SMP x86).
Dms software reengineering toolkit full#
(DMS also handles full C++14.)ĬloneDR, a leading clone detection tool
If you think, as I do, that Stack Overflow is about providing good answers (in list form or not) regardless of who provides them, you can take up that case in Meta. And opinions from old hands and smart people are often pretty useful in making a good choice. So what? People either like their tools or they don't. Related to this is the problem of SO moderators closing tool questions in general (what? programming is about using tools!), because "answers are likely to be opinionated". So, I expect to respond to further questions at likely a lower rate.
Since these tools are what I live and breathe, most of what I have say that is constructive is thus unwanted. Oct 2012: The "moderator community" at Meta has convinced me that answers I provide that mention my company's software tools are unwanted (at least by many of them) on Stack Overflow, in spite of the fact that my upvote score per answer averages the same as Jon Skeet's note moderator deletions of many of my tool answers. I have been building highly automated software engineering tools and systems software for 45 years (more below).
0 kommentar(er)
