Sample
Schnappinger/argoUML/org.argouml.cognitive.ui.ToDoByType
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 34.8Δ 25.9 |
| Scalabrino | 0.588 | 0–1; higher is more readable | 20.5Δ 11.6 |
| Dorn | 0.177 | 0–1; higher is more readable | 39.3Δ 30.4 |
| Mi | 0.577 | 0–1; higher is more readable | 53.8Δ 44.9 |
| LLOC | 70 | Logical lines; fewer is more readable | 29.7Δ 20.8 |
| DeepSeek V4 Pro | 7.67 | 0–20; mean of three runs | 5.4Δ 3.5 |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs | 9.4Δ 0.5 |
| BTTF | 0.502 | 0–1; higher is more readable | 44.9Δ 36.0 |
| Human | 2.11 | 1–4; original rating | 8.9 |
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. | 4492.402 | −148.249 |
| Source linesThe number of non-empty source lines. | 178 | +71.2 |
| 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.13 | −7.695 |
Intercept 8.87 + feature contributions = -75.875 (log-odds).
Score = sigmoid(-75.875) = 0.
| Score | 0.588 |
|---|
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. | 179 | −5.302 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 126 | +3.621 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 126 | −2.47 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 177.629 | +2.073 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 103.38 | +0.864 |
| 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. | 103.983 | −0.739 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.061 | +0.349 |
Intercept 0.07 + feature contributions = -1.534 (log-odds).
Score = sigmoid(-1.534) = 0.177.
| Score | 0.577 |
|---|
| Score | 70 |
|---|
Run 1
The code has some positive aspects like basic structure and method separation, but suffers from major readability issues. There is significant code duplication between toDoItemsChanged and toDoItemsAdded methods, both containing nearly identical nested loops to count and collect matching items. The mixed indentation (spaces vs tabs) disrupts reading flow. Methods like toDoItemsChanged have too many nested levels and multiple actions per loop iteration, making the logic hard to follow. The variable names (ktn, kt, tde) are cryptic. Comments are sparse and one commented-out line exists (fireTreeNodesChanged). The overall intent requires significant effort to understand due to intertwined counting and collection logic across two passes over the same data.
Run 2
The code structure is acceptable with clear methods, but there is significant code duplication between `toDoItemsChanged` and `toDoItemsAdded`. Nesting is moderate (3 levels), but the duplicated loops create unnecessary length. Indentation is inconsistent (tabs vs spaces), disrupting reading flow. The intent is mostly clear—handling ToDo list events by knowledge type—but the repeated filtering logic obscures it. Action granularity is reasonable (one primary action per line), though some logical blocks could be extracted. The overall clarity is undermined by copy-pasted code, inconsistent formatting, and a lack of helper methods to consolidate the matching/filtering logic.
Run 3
The code has clear class-level structure and method separation, but the readability is undermined by several issues. The method bodies contain duplicated logic across toDoItemsChanged and toDoItemsAdded, making it unnecessarily long. Indentation is inconsistent—mixing tabs and spaces—which disrupts reading flow. The methods use deep nesting (up to four levels) and multiple actions per block, making the logic harder to follow. Variable names like 'ktn' and 'kt' are terse and lack clarity. There is dead code (commented-out fireTreeNodesChanged) and logging statements with vague messages. The overall intent is discernible but requires effort due to repetition and inconsistent formatting. Refactoring the duplicate filtering logic into a helper method, improving variable names, and standardizing indentation would significantly enhance readability.
Run 1
Code Structure: Clearly organized into a constructor and listener callbacks, but the changed and added handlers duplicate nearly all their logic. Nesting: Moderate loop-within-loop nesting remains manageable, and continue statements reduce deeper conditional nesting. Clarity of intent: Class and callback names explain the purpose, but abbreviations such as ktn, kt, and anyInKT require interpretation; the PriorityNode log message is misleading. Code length: Repeated counting and collection passes, extensive boilerplate comments, and duplicated handlers make the file longer than necessary. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Each handler follows a predictable sequence, but inconsistent indentation, resetting and reusing nMatchingItems, a commented-out call, and an unexplained empty callback interrupt readability.
Run 2
Code Structure: Listener methods are logically separated, but added and changed handlers duplicate nearly all their logic. Nesting: Moderate loop-within-loop nesting is manageable, and continue statements avoid deeper conditional blocks. Clarity of intent: Class documentation and descriptive method names explain the purpose, but abbreviations such as kt, ktn, and anyInKT require interpretation; the PriorityNode log message is misleading. Code length: Repeated filtering passes, duplicated handlers, extensive boilerplate, and a commented-out call increase reading effort. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Each handler follows a recognizable sequence, but inconsistent tab/space indentation, mutable array bookkeeping, and resetting the matching counter interrupt smooth reading.
Run 3
Code Structure: Clearly organized into a constructor and listener callbacks, but added/changed handlers duplicate substantial logic. Nesting: Moderate loop-and-condition nesting; continue statements prevent deeper branching. Clarity of intent: Class documentation and callback names convey the purpose, while abbreviations such as ktn, kt, and anyInKT require interpretation. A misleading PriorityNode log message and commented-out call add confusion. Code length: Repeated two-pass filtering, extensive boilerplate, and redundant comments make the file longer than necessary. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Each handler follows a predictable sequence, but inconsistent indentation, repeated blocks, and mutable counter reuse interrupt otherwise straightforward reading.