Sample
Schnappinger/aoi/artofillusion.keystroke.KeystrokeEditor
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 27.1Δ 1.3 |
| Scalabrino | 0.556 | 0–1; higher is more readable | 14.7Δ 11.0 |
| Dorn | 0.214 | 0–1; higher is more readable | 41.9Δ 16.2 |
| Mi | 0.444 | 0–1; higher is more readable | 27.1Δ 1.3 |
| LLOC | 59 | Logical lines; fewer is more readable | 35.3Δ 9.6 |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs | 59.9Δ 34.2 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 29.5 |
| BTTF | 0.438 | 0–1; higher is more readable | 38.0Δ 12.2 |
| Human | 3 | 1–4; original rating | 25.7 |
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. | 5688.705 | −187.727 |
| Source linesThe number of non-empty source lines. | 119 | +47.6 |
| 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.064 | −7.596 |
Intercept 8.87 + feature contributions = -138.854 (log-odds).
Score = sigmoid(-138.854) = 0.
| Score | 0.556 |
|---|
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. | 120 | −3.212 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 101 | +2.756 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 101 | −1.897 |
| 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. | 118.967 | −1.374 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 118.95 | +1.253 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 118.967 | +1.115 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.098 | −0.01 |
Intercept 0.07 + feature contributions = -1.298 (log-odds).
Score = sigmoid(-1.298) = 0.214.
| Score | 0.444 |
|---|
| Score | 59 |
|---|
Run 1
The code is generally readable and well-structured. The class has a clear single responsibility (editing a keystroke record) and uses a logical organization with fields, constants, and methods grouped together. Naming is mostly clear, and methods are concise with single-action lines in most places. However, there are some readability issues: the constructor is quite long and performs many UI setup actions, reducing clarity. The 'setKey' method uses a short loop with inline logic that could be slightly clearer. LayoutInfo and FormContainer usage creates visual noise. The constant RESERVED_CODES is well-intentioned but the loop to check it is slightly verbose. Some lines are dense (e.g. the keyField creation line), decreasing flow. Overall, it is readable but not exemplary—deductions are due to constructor length, occasional dense lines, and UI layout code that could be extracted for better flow.
Run 2
The code is highly readable with a clear, logical structure. The class has cohesive fields, a well-defined public API, and private methods that each perform one clear action. Nesting is minimal—only a single loop in setKey() and no deeply nested conditionals. The intent of each method is obvious from its name and the code is concise without being terse. Action granularity is good: most lines perform a single UI setup or assignment step. The reading flow is natural, following a top-down progression from license, imports, Javadoc, fields, constructor, to event handlers. Minor deductions are for slightly dense layout in the constructor where many UI components are configured consecutively, and the bitwise modifier calculation could be more explicit. Overall, the code is approachable for a maintainer with even moderate Java Swing experience.
Run 3
The code is well-structured and readable. It has clear separation of concerns: UI setup, event handling, and utility methods. The constructor is somewhat long due to form layout configuration, but it follows a logical sequence. Nesting is minimal, with a single loop in setKey and a guard clause for reserved keys. Variable and method names are self-documenting, and Javadoc comments explain the public API. Action granularity is generally one action per line, especially in event handlers. The reading flow is natural—fields, constants, constructor, then methods. Potential improvements: the FormContainer layout could be extracted into a helper method for better readability, and the magic numbers (0,1,2,3,4,5) for grid positions could be named constants. Overall, the code maintains good clarity despite the inherent complexity of Swing-like UI layout code.
Run 1
Code Structure: Well organized into dialog creation, confirmation, cancellation, validation, and key handling methods, although the constructor combines many UI setup responsibilities. Nesting: Minimal nesting; the reserved-key loop is simple, but omitted braces slightly reduce readability. Clarity of intent: Descriptive names and method documentation make the purpose clear. However, the class comment references a nonexistent editKeystroke() method, string-based event handlers obscure navigation, and numeric layout parameters require framework knowledge. Code length: Generally concise, with a moderately long constructor that could benefit from grouped setup helpers. Action granularity: Statements consistently perform one main action per line. Reading flow: Initialization proceeds naturally from controls to layout to buttons, followed by short event handlers. Sparse visual grouping in the constructor and wildcard imports are minor impediments.
Run 2
Code Structure: Clearly organized into dialog setup and small, focused event handlers, though the constructor could separate widget creation from layout. Nesting: Mostly flat, with only a shallow loop and conditional in setKey; omitted braces slightly hinder scanning. Clarity of intent: Descriptive names and documentation explain the purpose, but the class comment references a nonexistent editKeystroke() method, and numeric layout arguments require interpretation. Code length: Appropriately concise overall, although the constructor is relatively dense. Action granularity: Generally one operation per line; the modifier expression would benefit from spacing and clearer bitwise notation. Reading flow: Natural progression from fields and constants to construction and handlers, with consistent formatting. String-based event links and several long layout statements modestly reduce readability.
Run 3
Code Structure: Well organized into dialog construction, confirmation/cancellation handlers, validation, and key capture, though the constructor could separate widget setup from layout. Nesting: Mostly flat, with only a shallow loop and conditional in setKey; omitted braces slightly reduce clarity. Clarity of intent: Descriptive names and documentation make the purpose clear, but the class comment references a nonexistent editKeystroke() method, and numeric layout arguments and string-based event links require interpretation. Code length: Appropriately concise overall, although the constructor is relatively long and dense. Action granularity: Generally one action per line; combined field declarations and modifier-mask arithmetic are minor exceptions to straightforward presentation. Reading flow: Methods follow a natural progression from opening and building the dialog to handling user actions, with consistent formatting. Wildcard imports and several long layout expressions modestly hinder scanning.