Sample

Scalabrio29

Human rating uses the original dataset scale.

DatasetScalabrino
Human3.67
Lines21

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
62.3Δ 9.3
Scalabrino0.4520–1; higher is more readable
43.2Δ 9.8
Dorn0.3210–1; higher is more readable
38.7Δ 14.3
Mi0.0260–1; higher is more readable
13.1Δ 39.9
LLOC8Logical lines; fewer is more readable
76.9Δ 23.9
DeepSeek V4 Pro13.330–20; mean of three runs
38.7Δ 14.3
GPT-6.1 Sol160–20; mean of three runs
34.7Δ 18.3
BTTF0.570–1; higher is more readable
64.3Δ 11.3
Human3.671–5; original rating
53.0

Views

Download official ZIP ↗

Select the downloaded ZIP or its extracted folder. Files stay in your browser.

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.452

Feature contributions

FeatureValueContribution
(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.

Score0.026
Score8
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.