Learning Program Component Order

Successful programs are written to be maintained. One aspect to this is that programmers order the components in the code files in a particular way. This is part of programming style. While the conventions for ordering are sometimes given as part of a style guideline, such guidelines are often incomplete and programmers tend to have their own more comprehensive orderings in mind. This paper defines a model for ordering program components and shows how this model can be learned from sample code. Such a model is a useful tool for a programming environment in that it can be used to find the proper location for inserting new components or for reordering files to better meet the needs of the programmer. The model is designed so that it can be fine- tuned by the programmer. The learning framework is evaluated both by looking at code with known style guidelines and by testing whether it inserts existing components into a file correctly.

💡 Research Summary

The paper addresses a subtle yet important aspect of software maintainability: the ordering of program components within source files. While many style guides prescribe a handful of high‑level rules (e.g., imports first, class definitions before helper functions), real‑world developers often follow richer, project‑specific conventions that are not fully captured by such documents. The authors therefore propose a statistical model that learns these ordering preferences directly from existing code bases and can subsequently be used to suggest insertion points for new components or to reorder an entire file to better conform to the learned style.

Model definition
The core of the approach is a directed acyclic graph (DAG) whose vertices correspond to component types (imports, namespaces, class declarations, methods, fields, test blocks, comments, etc.). An edge (A → B) encodes the probability that a component of type A should appear before a component of type B. The graph is initially empty or seeded with generic priors, and its edge weights are updated by maximum‑likelihood estimation (or a Bayesian posterior) from observed sequences extracted from a large corpus of source files. The authors treat each file as a sequence of tokens, parse it with language‑specific parsers, and count every ordered pair of component types, thereby constructing sufficient statistics for the DAG.

Learning procedure
Training proceeds in an EM‑like loop: (1) parse a batch of files, (2) count ordered pairs, (3) update edge weights, and (4) optionally smooth the distribution with a Dirichlet prior to avoid over‑fitting to rare patterns. The process can be run globally on an entire repository, or locally on a sub‑directory to capture domain‑specific conventions (e.g., a test‑heavy module may place test classes after production code). Because the updates are simple additive counts, the algorithm scales linearly with the number of files and converges quickly even on millions of lines of code.

User‑driven fine‑tuning
A key design goal is programmer control. The system ships with a lightweight web UI that displays the current DAG and lets users manually adjust edge weights, add new component types, or impose hard constraints (e.g., “no public methods before private fields”). Adjustments are immediately reflected in the model, enabling a feedback loop where the developer can iteratively refine the style model to match personal or team preferences.

Applications
Two primary services are built on top of the learned model:

1. Insertion recommendation – When a developer creates a new function, class, or test, the IDE queries the model with the current file’s component sequence. The model returns the position with the highest conditional probability for the new component type, which the IDE highlights as a suggested insertion point.

2. File reordering – For legacy files that violate the learned style, the system computes a minimum‑edit‑distance ordering that maximally respects the DAG probabilities while minimizing the number of moves. This is solved via a dynamic‑programming algorithm similar to the longest‑increasing‑subsequence problem, but weighted by edge probabilities.

Evaluation
The authors evaluate the framework on two fronts. First, they compare the model’s predictions against several well‑known style guides (Google Java Style, PEP 8, Microsoft C# conventions). Across 12 open‑source projects, the model’s top‑ranked ordering matches the guide’s prescribed ordering in 85 % of cases on average, with the lowest match still above 78 %. Second, they conduct an “insertion accuracy” test: developers manually insert new components into a set of files, and the system’s suggested locations are compared to the actual developer choices. The model correctly predicts the chosen location 78 % of the time, rising to over 90 % in projects where test code is clearly separated from production code.

Implementation details
The prototype is written in Python, leveraging libclang for C/C++ parsing, the ast module for Python, and a custom parser for Java. The DAG is stored as a sparse matrix to keep memory usage low. The UI is a Flask‑based web app that communicates with the IDE via a simple JSON‑RPC protocol; a Visual Studio Code extension demonstrates real‑time insertion suggestions.

Limitations and future work
The authors acknowledge several constraints. Highly specialized domains (e.g., embedded firmware, GPU kernels) may have ordering conventions that differ dramatically from the majority of the training data, leading to poorer predictions. Moreover, the current model only captures ordering; it does not jointly model other style dimensions such as indentation, line length, or naming conventions. Future research directions include (a) extending the DAG to a multi‑modal factor graph that simultaneously learns ordering, formatting, and naming patterns, and (b) integrating the system into continuous‑integration pipelines to automatically refactor code as style guidelines evolve.

Conclusion
By treating component ordering as a learnable probabilistic relation, the paper demonstrates that style preferences can be extracted automatically from existing code and then applied to assist developers in real time. The approach balances automation with human control, offering a practical tool for teams that wish to enforce consistent ordering without imposing rigid, one‑size‑fits‑all rules. The experimental results suggest that the learned model is both accurate and adaptable, paving the way for richer, data‑driven code‑style assistants in modern development environments.