Sample
Scalabrio29
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 62.3Δ 9.3 |
| Scalabrino | 0.452 | 0–1; higher is more readable | 43.2Δ 9.8 |
| Dorn | 0.321 | 0–1; higher is more readable | 38.7Δ 14.3 |
| Mi | 0.026 | 0–1; higher is more readable | 13.1Δ 39.9 |
| LLOC | 8 | Logical lines; fewer is more readable | 76.9Δ 23.9 |
| DeepSeek V4 Pro | 13.33 | 0–20; mean of three runs | 38.7Δ 14.3 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 34.7Δ 18.3 |
| BTTF | 0.57 | 0–1; higher is more readable | 64.3Δ 11.3 |
| Human | 3.67 | 1–5; original rating | 53.0 |
Views
Select the downloaded ZIP or its extracted folder. Files stay in your browser.
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. | 621.476 | −20.509 |
| Source linesThe number of non-empty source lines. | 21 | +8.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. | 5.028 | −7.542 |
Intercept 8.87 + feature contributions = -10.78 (log-odds).
Score = sigmoid(-10.78) = 0.
| Score | 0.452 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 164 | −3.281 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 164 | +1.842 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 21 | +0.293 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.075 | +0.211 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 17 | −0.149 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 19.709 | −0.134 |
Intercept 0.07 + feature contributions = -0.751 (log-odds).
Score = sigmoid(-0.751) = 0.321.
| Score | 0.026 |
|---|
| Score | 8 |
|---|
Run 1
The code is well-structured and readable. It has a clear purpose: determining if a class type is an entity. The first if statement handles non-entity cases, with inline comments explaining each condition. Nesting is shallow (only one level deep inside the first if block), making the logic easy to follow. The second if block validates the entity requirement concisely. Action granularity is good, with one logical action per line (method calls, returns, comparisons). The exception message is readable, though the string concatenation for clazzToProcess.getName() adds minor length. The code flow is natural: it filters out special cases first, handles a potential error condition, then returns true. Minor improvements could include replacing magic literals with named constants and simplifying the nested check for AnnotatedClassType.NONE, but overall this is clean, maintainable code. Score reduced slightly due to the repeated classType comparisons and the slightly verbose exception construction.
Run 2
The method has a clear purpose and the early return pattern is good. However, readability is hindered by several issues: the nested if block adds depth, the condition ordering places NONE last while its special handling comes first, and the embbeddable comment is misleading. The repeated use of 'AnnotatedClassType' creates verbosity. The first condition mixes multiple checks, and the inner if is a side-effect that feels disconnected. The method could be simplified by extracting the NONE check and restructuring conditions. The comments are somewhat helpful but not always clear. The annotation exception message is long and would benefit from a constant. Overall, functional but not optimally structured for readability.
Run 3
The code has clear intent and simple logic, but suffers from several readability issues. The first if statement contains redundant checks on classType, making the logic harder to follow. There are multiple actions on a single line with trailing comments creating visual clutter. The dot-chained method call splits awkwardly across lines, interrupting the reading flow. The nesting level is moderate, but the nested if block could be restructured for clarity. The method name and parameter names are descriptive, which helps understanding. Comments provide useful context but are placed at line ends rather than above. Overall, the code could be improved by consolidating the classType checks, simplifying the nested condition, and formatting the exception message construction more cleanly to enhance readability.
Run 1
Code Structure: Logically separates excluded class types, annotation validation, and successful classification. Nesting: Mostly flat, with only one nested conditional for logging. Clarity of intent: Descriptive names and explicit enum comparisons communicate the purpose, though the comments are terse and the distinction between exclusion and invalid classification requires attention. Code length: Appropriately short, but repeated comparisons and the lengthy exception message add visual bulk. Action granularity: Each statement performs a single action; the compound condition combines related checks appropriately. Reading flow: Early returns make the control flow easy to follow, but uneven wrapping, inline comments within the condition, and the split getName() call interrupt scanning.
Run 2
Code Structure: Logically organized into excluded types, validation, and a successful return. Nesting: Shallow overall, with only one nested conditional for logging. Clarity of intent: The method name and enum values clearly communicate entity classification, although returning false for some types while throwing for others requires careful reading. Code length: Appropriately short, but repeated comparisons and the lengthy exception message add visual bulk. Action granularity: Each statement performs a single clear action. Reading flow: Early returns support a natural top-to-bottom progression, while uneven line wrapping, inline comments within the condition, and the split getName() call slightly disrupt readability.
Run 3
Code Structure: Logically organized into excluded-type handling, validation, and success. Nesting: Shallow overall, with only one nested condition for logging. Clarity of intent: The method name and enum constants convey its purpose, although the exception and logging side effects go beyond a simple boolean predicate. Inline comments help explain exclusions but are terse. Code length: Appropriately concise, though repeated comparisons add some verbosity. Action granularity: Each statement performs one action; the combined condition groups related exclusions coherently. Reading flow: Early returns make the control flow easy to follow, but awkward wrapping of the exception message and getName() call, fully qualified annotation names, and inconsistent equality style slightly impede readability.