Sample
int-e023e571a15c-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.135 | 0–1; higher is more readable |
| Scalabrino | 0.57 | 0–1; higher is more readable |
| Dorn | 0.769 | 0–1; higher is more readable |
| Mi | 0.727 | 0–1; higher is more readable |
| LLOC | 12 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.631 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 840.254 | −27.728 |
| Source linesThe number of non-empty source lines. | 60 | +24 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 4.665 | −6.998 |
Intercept 8.87 + feature contributions = -1.856 (log-odds).
Score = sigmoid(-1.856) = 0.135.
| Score | 0.57 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 58 | −1.017 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.721 | +0.756 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 40 | +0.646 |
| Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names. | 99.984 | −0.57 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.488 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 59.941 | +0.428 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 1.2 (log-odds).
Score = sigmoid(1.2) = 0.769.
| Score | 0.727 |
|---|
| Score | 12 |
|---|
Run 1
This interface is highly readable and well-structured. The code organization is logical, with method declarations grouped into sections (adjacent nodes, incident edges, edge operations) and separated by whitespace. Nesting is minimal - only the class/interface declaration and method bodies are nested, making the code flat and easy to scan. Intent is crystal clear through descriptive method names and purposeful Javadoc comments that explain each method's behavior and edge cases. The code length is concise - no unnecessary boilerplate or redundant annotations. Action granularity is appropriate for an interface, with each method declaration on its own line. Reading flow is natural, moving from basic accessor methods to more complex edge operations in a progressive manner. The only minor deduction is for the slightly verbose Javadoc on some methods, but this actually enhances understanding rather than hindering readability. Overall, this is exceptionally clean, well-documented Java code.
Run 2
The code is highly readable. It defines a clear, well-documented interface with logical method grouping—adjacency, edges, and mutation operations are cleanly separated. Nesting is absent as it is an interface, and each method declaration is concise, typically fitting on one line. Javadoc comments clarify intent, especially for nuanced behaviors like self-loops and edge directionality. Method names are descriptive and align with graph theory terminology, enhancing clarity. The annotations (@CanIgnoreReturnValue, @Nullable) further improve understanding of method contracts. The code avoids unnecessary length while maintaining completeness. Overall, structure and flow are natural and easy to follow. Minor deductions are due to slight repetition in method documentation patterns, but this does not meaningfully affect readability.
Run 3
This code is highly readable due to its clean structure and clear purpose. The interface is logically organized with all getter methods grouped together first, followed by mutator methods. There is minimal nesting — only a single level for the interface and its method declarations. Each method has a clear, descriptive name that conveys its intent, and concise Javadoc comments clarify ambiguous behavior (e.g., directed vs undirected cases). Code length is appropriate, with no unnecessary verbosity. Each method declaration occupies a single line, maintaining good action granularity. The reading flow is natural and intuitive, progressing from general accessors to specific edge operations. Minor potential improvements could include adding Javadoc for every method, but overall readability is excellent.
Run 1
Code Structure: The interface logically groups node queries, edge queries, and mutation methods. Nesting: Flat method declarations have no nested control flow. Clarity of intent: Descriptive names, generic types, annotations, and focused documentation clearly express purpose and important directed/undirected behavior. Code length: Concise declarations and relevant comments avoid unnecessary verbosity. Action granularity: Each declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent formatting and progression from queries to mutations make scanning natural. Minor drawbacks are the undocumented basic query methods and the unexplained isSelfLoop parameter on addInEdge.
Run 2
Code Structure: The interface logically groups node queries, edge queries, and mutation methods. Nesting: The structure is flat, with no nested control flow. Clarity of intent: Descriptive method names, generic type documentation, and focused Javadocs clearly communicate purpose; annotations clarify nullability and return-value handling. Code length: Declarations and comments are concise without unnecessary implementation detail. Action granularity: Each method declaration occupies its own line and represents a focused operation. Reading flow: Consistent formatting and progression from queries to mutations make the interface easy to scan. Minor limitations are the lack of documentation for the initial query methods and limited explanation of the isSelfLoop parameter in addInEdge.
Run 3
Code Structure: The interface logically groups node queries, edge queries, removals, and additions. Nesting: Flat method declarations have no nested control flow. Clarity of intent: Descriptive method names, generic types, annotations, and targeted documentation make the contract clear, though the initial query methods lack documentation and addInEdge does not explain isSelfLoop. Code length: Concise declarations and relevant comments avoid unnecessary verbosity. Action granularity: Each declaration occupies its own line, with annotations clearly separated where appropriate. Reading flow: Consistent formatting and query-before-mutation ordering support natural reading; a blank line after the package declaration would slightly improve visual separation.