Do Developers Read Type Information? An Eye-Tracking Study on TypeScript

Statically-annotated types have been shown to aid developers in a number of programming tasks, and this benefit holds true even when static type checking is not used. It is hypothesized that this is because developers use type annotations as in-code documentation. In this study, we aim to provide evidence that developers use type annotations as in-code documentation. Understanding this hypothesized use will help to understand how, and in what contexts, developers use type information; additionally, it may help to design better development tools and inform educational decisions. To provide this evidence, we conduct an eye tracking study with 26 undergraduate students to determine if they read type annotations during code comprehension and bug localization in the TypeScript language. We found that developers do not look directly at lines containing type annotations or type declarations more often when they are present, in either code summarization or bug localization tasks. The results have implications for tool builders to improve the availability of type information, the development community to build good standards for use of type annotations, and education to enforce deliberate teaching of reading patterns.

💡 Research Summary

The paper investigates whether developers actually read type annotations in TypeScript code, treating them as in‑code documentation. To answer this, the authors conducted an eye‑tracking study with 26 undergraduate participants (22 usable datasets after exclusions). Participants performed two kinds of tasks: code summarization and bug localization. For each task, they were presented with paired code snippets—one version containing full type annotations and another with all type information stripped. The code samples were drawn from real‑world GitHub Gists, Rosetta Code, and custom‑written examples, covering a range of sizes, libraries, and programming styles (functional, object‑oriented, etc.).

Before the main tasks, participants completed a working‑memory assessment (operation‑span task) to explore any correlation between cognitive capacity and reading behavior. Eye‑tracking data were collected using the iTrace framework, capturing dwell time, fixation count, and a specific “reference behavior” metric that records whether a participant looks directly at lines containing type declarations or revisits them later.

Statistical analysis revealed three core findings. First, the presence of type annotations did not lead to a statistically significant increase in dwell time or fixation count on annotated lines. In other words, developers did not spend more time looking at or revisiting type‑rich lines compared to unannotated code. Second, the “reference behavior” metric showed no meaningful difference between annotated and non‑annotated conditions, indicating that developers rarely treat type lines as focal points during comprehension or debugging. Third, participants with higher working‑memory scores exhibited a slight uptick in fixation on annotated lines, but the effect size was negligible and did not translate into measurable performance gains on the tasks.

These results challenge the common assumption that static type annotations serve primarily as documentation that developers actively read. Instead, the data suggest that developers treat type information as a peripheral resource—consulted only when needed and otherwise relying on variable names, function signatures, comments, and code structure for understanding. The authors discuss implications for tool builders: IDEs could make type information more discoverable through hover tooltips, color‑coding, or contextual suggestions, rather than assuming developers will notice it in the code flow. For educators, the findings imply that teaching should explicitly address when and how to consult type annotations, rather than assuming students will naturally use them as documentation.

The study’s limitations include the homogeneity of the participant pool (mostly undergraduate students) and the relatively small, self‑contained code snippets used in the experiment. Real‑world industrial settings involve larger codebases, more complex type hierarchies, and developers with varied experience levels, which could yield different eye‑movement patterns. Future work is suggested to broaden participant demographics, incorporate longitudinal studies on maintenance tasks, and combine eye‑tracking with other metrics such as bug‑fix time and code change size.

In conclusion, the eye‑tracking evidence indicates that type annotations in TypeScript do not attract additional visual attention during typical comprehension and bug‑localization tasks. While they may still provide valuable background information, developers appear to read them infrequently and only on an as‑needed basis. This insight informs the design of programming environments, documentation practices, and curricula aimed at leveraging static type information more effectively.