Researchers as well as practitioners often use static dependency graphs as a foundation for their investigations on the structure of a program. They are gathered by compiler-like static analyzers that are specific to a programming language. If more than one programming language is to be analyzed, different static analyzers need to be used, each having its own data structures and APIs, which increases the integration effort. To reduce this integration effort to a minimum, a standard mechanism to obtain dependency information would be of great help. The language server protocol (LSP) is such a standardized mechanism. It was developed in the context of multi-language integrated development environments (IDE) to implement interactive features such as auto-complete or code navigation. In this paper, we investigate whether LSP can be used to create static dependency graphs in a non-interactive way for$\mathrm{C}++, \mathrm{C} #$, Go, Java, JavaScript/TypeScript, Python, and Rust. Our use case differs from LSP's original purpose by the magnitude of the queries for nodes and edges, potentially bringing the language servers to their limits. We assess the scalability of the various language servers available for these languages and take a look at how various size metrics affect the different run-time phases. We found that LSP is a real help in integrating different tools to create static dependency graphs in a uniform way. Adding a different language server for a new language requires very little effort. Yet, scalability is a real issue. The gathering of the dependency data can take hours for large projects. The expected run-time for the analyses can be predicted as a linear function of the lines of code or number of files to be processed, allowing one to estimate in advance when a result can be expected.

This paper presents a study in which we compared the visualization of code smells in Code Cities with classical tabular representations. We conducted a controlled experiment with 20 participants who had to solve six tasks in both environments. We evaluated the results of our experiment statistically and came to the following conclusions: In four tasks the completion time was significantly lower when using Code Cities (the remaining two tasks did not show any statistically significant differences for any of the two environments). Also, the perceived effort was significantly lower in three tasks when the participants used Code Cities over the tabular representation (again, the remaining tasks did not show any statistically significant differences). However, with regard to the perceived usability (which was measured across all tasks) and the correctness of the supplied answers, the tabular representation performed better. In particular, in two tasks the correctness was significantly better in the tabular environment and in one task the correctness was significantly better in the Code Cities environment. Based on our results, our verdict is as follows: Code Cities are better suited to get a quick overview of the code smells of a software, whereas tabular representations are better suited to analyze code smells in more detail.Experiment data, evaluation scripts and supplemental material: https://github.com/uni-bremen-agst/VISSOFT2022/archive/ refs/tags/1.0.0.zip (see README.md in the ZIP archive)