Source code
int eventId = active? ON : OFF;
ActionEvent blinkEvent = new ActionEvent(this,eventId,"blink");
fireActionEvent(blinkEvent);
Sample
Buse/20
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.65 | 0–1; higher is more readable | 70.7Δ 25.8 |
| Scalabrino | 0.564 | 0–1; higher is more readable | 24.2Δ 20.7 |
| Dorn | 0.558 | 0–1; higher is more readable | 40.4Δ 4.5 |
| Mi | 0.334 | 0–1; higher is more readable | 20.2Δ 24.7 |
| LLOC | 3 | Logical lines; fewer is more readable | 88.9Δ 43.9 |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs | 98.5Δ 53.5 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 96.0Δ 51.0 |
| BTTF | 0.418 | 0–1; higher is more readable | 26.3Δ 18.7 |
| Human | 3.26 | 1–5; original rating | 44.9 |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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.091 | −6.137 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 112.588 | −3.715 |
| Source linesThe number of non-empty source lines. | 4 | +1.6 |
Intercept 8.87 + feature contributions = 0.618 (log-odds).
Score = sigmoid(0.618) = 0.65.
| Score | 0.564 |
|---|
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. | 4 | +0.895 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| 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. | 71 | +0.658 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 3.819 | −0.356 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.089 | +0.077 |
Intercept 0.07 + feature contributions = 0.234 (log-odds).
Score = sigmoid(0.234) = 0.558.
| Score | 0.334 |
|---|
| Score | 3 |
|---|
Run 1
The code is highly readable. It has a clear logical structure: initialize an event ID, create an event object, and fire the event. Nesting is non-existent, keeping the flow flat and straightforward. The intent is clear—triggering a blink action event—though using a ternary for eventId adds minor ambiguity without context. The length is concise with no unnecessary lines. Each action is on its own line, respecting action granularity. The reading flow is natural and sequential.
Run 2
The code is highly readable. It has a clear, logical structure with an obvious purpose: preparing and firing an action event. Nesting is absent, and clarity of intent is strong, using descriptive variable names like eventId and blinkEvent. The code is concise and not unnecessarily long. Action granularity is good, with one main action per line, and the reading flow is natural—determine the event ID, construct the event, then fire it. Minor deductions for the ternary expression, which slightly compresses two actions into one line, and the ambiguous strings 'blink', 'ON', and 'OFF' that rely on external definitions or comments for full context.
Run 3
The code is highly readable. It has a clear, flat structure with no nesting. Intent is immediately apparent: construct an event ID based on a boolean condition, create an ActionEvent with a descriptive label, and dispatch it. Each line performs a single logical action. The variable names are descriptive, and the ternary operator is used appropriately to keep the code concise. Only minor improvements might include adding a comment for context or using a more descriptive variable name than 'blinkEvent', but overall the code is very clean and maintainable.
Run 1
Code Structure: Logically organizes event ID selection, event creation, and dispatch. Nesting: Flat, with no nested blocks. Clarity of intent: Descriptive names and the "blink" command make the purpose clear, though ON/OFF definitions require external context. Code length: Concise, with no unnecessary statements. Action granularity: Each line performs one distinct action. Reading flow: Natural progression from determining state to constructing and firing the event. Minor spacing inconsistencies around the ternary operator and constructor arguments slightly reduce polish.
Run 2
Code Structure: Logically organized into choosing an event ID, constructing an event, and firing it. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive variable names and the "blink" command make the purpose clear, though ON and OFF depend on surrounding context. Code length: Concise without unnecessary statements. Action granularity: Each line performs one distinct action. Reading flow: Natural progression from preparation to dispatch; minor spacing inconsistencies around the ternary operator and constructor arguments slightly reduce polish.
Run 3
Code Structure: Logically organized into event ID selection, event creation, and dispatch. Nesting: Flat, with no nested control flow. Clarity of intent: Variable names and the "blink" command clearly indicate the purpose, although ON and OFF depend on external definitions. Code length: Concise without unnecessary steps. Action granularity: Each line performs one distinct action. Reading flow: Natural progression from determining state to constructing and firing the event. Minor spacing inconsistencies around the ternary operator and constructor arguments slightly reduce readability.