Sample
int-5e5288c771df-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.016 | 0–1; higher is more readable |
| Scalabrino | 0.907 | 0–1; higher is more readable |
| Dorn | 0.817 | 0–1; higher is more readable |
| Mi | 0.616 | 0–1; higher is more readable |
| LLOC | 27 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.578 | 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. | 1820.128 | −60.064 |
| Source linesThe number of non-empty source lines. | 136 | +54.4 |
| 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.88 | −7.319 |
Intercept 8.87 + feature contributions = -4.114 (log-odds).
Score = sigmoid(-4.114) = 0.016.
| Score | 0.907 |
|---|
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. | 137 | −3.814 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 82 | +2.099 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 135.793 | +1.488 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.043 | +0.519 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 80.92 | +0.501 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 80.964 | +0.236 |
Intercept 0.07 + feature contributions = 1.498 (log-odds).
Score = sigmoid(1.498) = 0.817.
| Score | 0.616 |
|---|
| Score | 27 |
|---|
Run 1
The code is highly readable due to its clear structure, consistent formatting, and comprehensive Javadoc documentation. It uses flat nesting with only one level of synchronization, and each method performs a single logical action. Constructors are concise and delegate appropriately. The class follows Spring conventions, with fields clearly named and annotated for nullability. The use of a dedicated monitor object for synchronization is a good practice. Minor deductions: the empty constructor adds slight length, and the toString method could be marginally clearer, but overall the code is well-organized and easy to understand.
Run 2
The code is well-structured and highly readable. It follows a clean, logical organization with clear field declarations, constructors, and method implementations. Purpose is evident from comprehensive Javadoc comments, and intent is unambiguous. Nesting is minimal—only one synchronized block with a simple null check. Methods are concise and actions are generally one per line, promoting a natural reading flow. The class is reasonably sized, though some boilerplate (multiple constructors, monitor class) adds length but remains clear. Overall, the code maintains professional Spring framework standards with only minor verbosity.
Run 3
The code is highly readable with clear structure, minimal nesting, and explicit intent. Class organization is logical: fields, constructors, setters, and overridden methods follow a natural order. Nesting is flat—only a single synchronized block contains a conditional, which remains easy to follow. Method names and Javadoc comments clearly communicate purpose, especially for patterns and pointcut initialization. The code is concise but not terse; each line performs one logical action, and method lengths are short. Reading flow is natural and consistent with Spring conventions. Minor deductions: the nullable annotations on field declarations add slight visual noise, and the synchronized lazy-init block could be extracted for even greater clarity, but overall readability is excellent.
Run 1
Code Structure: Fields, constructors, configuration methods, pointcut initialization, and helpers are logically grouped. Nesting: Most methods are flat; getPointcut has three levels of nesting, justified by synchronized lazy initialization and optional pattern configuration. Clarity of intent: Descriptive names and useful Javadoc clearly explain the advisor, pattern matching, and extension point. The fact that changing patterns after initialization does not update the existing pointcut is less obvious. Code length: Implementation methods are concise, although repeated constructor documentation and generous whitespace increase overall length. Action granularity: Each statement generally performs one action, making state changes easy to follow. Reading flow: Consistent formatting and delegation create a natural progression from construction to configuration and use; the multiline toString expression and specialized nullable-array syntax introduce minor friction.
Run 2
Code Structure: Fields, constructors, configuration methods, initialization, and helper class are logically organized. Nesting: Most methods are flat; getPointcut has moderate, justified nesting for synchronization and lazy initialization. Clarity of intent: Descriptive names and detailed Javadoc clearly explain regex configuration, delegation, and defaults. Code length: Implementation is concise, though repeated constructor documentation and generous spacing slightly increase reading length. Action granularity: Statements generally perform one action per line, with constructor setup clearly separated. Reading flow: Consistent formatting and method ordering make the class easy to follow; the wrapped toString expression and dependency on inherited behavior introduce minor reading friction.
Run 3
Code Structure: Fields, constructors, configuration methods, initialization, and helpers are logically grouped. Nesting: Most methods are flat; getPointcut has modest nesting for synchronization and lazy initialization. Clarity of intent: Descriptive names and useful Javadoc explain pattern configuration, default implementation, and extension points. Code length: Implementation is concise, though repeated constructor documentation and generous spacing increase visual length. Action granularity: Statements generally perform one action per line, with straightforward delegation. Reading flow: Consistent formatting and method ordering make the class easy to follow. Minor friction comes from the multiline toString expression, specialized nullable-array syntax, and the need to understand inherited advisor behavior.