Sample
Schnappinger/jsweet/org.jsweet.transpiler.GlobalBeforeTranslationScanner
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 19.7Δ 19.4 |
| Scalabrino | 0.368 | 0–1; higher is more readable | 3.4Δ 3.1 |
| Dorn | 0.11 | 0–1; higher is more readable | 34.7Δ 34.3 |
| Mi | 0.628 | 0–1; higher is more readable | 68.0Δ 67.7 |
| LLOC | 70 | Logical lines; fewer is more readable | 29.7Δ 29.4 |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs | 18.8Δ 18.5 |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs | 9.4Δ 9.1 |
| BTTF | 0.226 | 0–1; higher is more readable | 14.2Δ 13.9 |
| Human | 1 | 1–4; original rating | 0.3 |
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. | 10080.7 | −332.663 |
| Source linesThe number of non-empty source lines. | 197 | +78.8 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.208 | −7.813 |
Intercept 8.87 + feature contributions = -252.806 (log-odds).
Score = sigmoid(-252.806) = 0.
| Score | 0.368 |
|---|
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. | 198 | −5.974 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 171 | +5.178 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 171 | −3.503 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 196.929 | +2.343 |
| 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. | 111.98 | −1.078 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 111.985 | +1.002 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.11 | −0.125 |
Intercept 0.07 + feature contributions = -2.087 (log-odds).
Score = sigmoid(-2.087) = 0.11.
| Score | 0.628 |
|---|
| Score | 70 |
|---|
Run 1
The code has some structural organization but suffers from several readability issues. The visitClassDef method is excessively long (50+ lines) and performs multiple unrelated operations: documentation processing, superclass analysis, inner class clash resolution, decorator registration, globals handling, and field analysis. This violates single responsibility and makes the method's purpose unclear. Nesting reaches 4-5 levels in places, making the logic hard to follow. Several lines combine multiple operations (e.g., checking multiple conditions with &&). Variable names are generally clear but some are cryptic (e.g., 'm', 'var'). The process method has complex boolean logic that is difficult to parse. While the code follows consistent formatting and has helpful comments, the dense, monolithic structure significantly impairs readability and maintainability.
Run 2
The code is generally well-structured and readable, with clear separation of concerns and descriptive method names. The class follows a logical flow: each visitor method handles a specific AST node type. However, readability suffers from several issues. The visitClassDef method is quite long (over 60 lines) and accumulates multiple responsibilities: documentation handling, class hierarchy analysis, inner class clash detection, field clash detection, static initialization tracking, and global method registration. Some deeply nested conditions appear, particularly in the field clash detection logic and the inner class handling, making the control flow harder to follow at a glance. Long qualified expressions and chained method calls (e.g., getEnclosingElement().getQualifiedName().toString().replace(...)) reduce readability. The lazyIn initializedStaticCandidates logic in process() uses a complex boolean condition that could be extracted for clarity. Minor positive aspects include consistent naming, useful comments, and one-action-per-line formatting in most places.
Run 3
The code has a clear structure with logical class organization and appropriate Javadoc comments. Imports are well-organized and the class purpose is evident. However, readability is hindered by several factors: long methods (visitClassDef is ~60 lines), multiple nested conditionals, and complex boolean expressions. Several lines contain multiple actions, such as the chained method calls in the clashingInnerClass mapping. The condition `context.getStaticInitializerCount(var.sym.enclClass()) == 0 && var.init == null || Util.isLiteralExpression(var.init)` lacks parentheses, making intent ambiguous. Variable names like 'm', 'var', and 'def' are somewhat generic. The code mixes different concerns within visitClassDef (doc comments, JDK subclass detection, inner class clashes, field mappings, static initializers), reducing clarity. While it follows standard Java patterns and uses descriptive method names overall, the density of logic and lack of helper method extraction for distinct blocks make it moderately difficult to follow.
Run 1
Code Structure: Visitor overrides logically organize analysis by AST node, but visitClassDef combines several responsibilities that would benefit from helper methods. Nesting: Field processing reaches roughly five nested control levels, making conditions harder to follow. Clarity of intent: Descriptive names, class documentation, and context method names explain most operations; terse variables and the mixed &&/|| condition in process obscure some details. Code length: Overall length is reasonable, but repeated documentation handling, redundant initialization, and verbose modifier checks add noise. Action granularity: Statements generally perform one action per line, though long chained expressions and compound conditions require extra effort. Reading flow: Consistent formatting and sequential visitor processing support navigation, but frequent casts, lengthy conditions, and switches between unrelated class-analysis tasks interrupt the flow.
Run 2
Code Structure: Visitor overrides logically separate AST node handling, but visitClassDef combines documentation collection, name-clash resolution, decorator registration, and static initialization analysis. Nesting: Several deeply nested conditions inside the member loop make paths difficult to follow. Clarity of intent: Descriptive class and API names plus introductory documentation establish the purpose, but short names such as m and def, complex predicates, and an unparenthesized mixed &&/|| condition reduce clarity. Code length: Mostly purposeful, though redundant initialization and verbose boolean assignment add noise; extracting helpers would simplify the longest method. Action granularity: Statements generally perform one action per line, with consistent formatting, although chained calls and casts create dense expressions. Reading flow: The visitor organization and final processing pass are natural, but repeated documentation handling and shifts between unrelated class-analysis tasks interrupt the flow.
Run 3
Code Structure: Visitor overrides provide logical organization, but visitClassDef combines documentation collection, inheritance analysis, name-clash resolution, and static initialization tracking. Nesting: Several conditionals inside the member loop reach substantial depth, making individual paths harder to follow. Clarity of intent: Descriptive class and API names and the class-level documentation explain the overall purpose; terse variables such as m and a mixed &&/|| condition without grouping obscure details. Code length: Reasonable overall, but redundant initialization, repeated casts and modifier checks, and duplicated documentation handling add avoidable verbosity. Action granularity: Most statements perform one action per line, although chained calls and long conditional expressions demand extra parsing. Reading flow: Consistent formatting and conventional visitor ordering help, but the large class visitor shifts between unrelated concerns and would read more naturally with focused helper methods.