Source code
Official dataset source · Dorn/java/155
Sample
Dorn/java/155
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.004 | 0–1; higher is more readable | 64.9Δ 1.4 |
| Dorn | 0.655 | 0–1; higher is more readable | 59.9Δ 6.4 |
| Mi | 0.344 | 0–1; higher is more readable | 33.7Δ 32.6 |
| LLOC | 10 | Logical lines; fewer is more readable | 59.5Δ 6.8 |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs | 91.4Δ 25.1 |
| GPT-6.1 Sol | 18.33 | 0–20; mean of three runs | 97.1Δ 30.8 |
| BTTF | 0.641 | 0–1; higher is more readable | 83.0Δ 16.7 |
| Human | 3.53 | 1–5; original rating | 66.3 |
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. | 367.872 | −12.14 |
| 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.233 | −6.35 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = -5.62 (log-odds).
Score = sigmoid(-5.62) = 0.004.
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. | 54 | +1.378 |
| 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 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| 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. | 5.2 | −0.337 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.098 | −0.007 |
Intercept 0.07 + feature contributions = 0.642 (log-odds).
Score = sigmoid(0.642) = 0.655.
| Score | 0.344 |
|---|
| Score | 10 |
|---|
Run 1
The code is highly readable due to its flat structure, consistent one-action-per-line granularity, and clear intent. Each line registers a single test suite, making the purpose unambiguous. The logical grouping of related test classes (AddPortlet, AddMB*, Search, View) provides structure. However, minor repetition could be reduced with a loop or helper method, and the lack of surrounding context slightly limits understanding of the overall flow. These small issues prevent a perfect score but do not significantly hinder readability.
Run 2
The code is straightforward and readable. It clearly shows a sequence of test suite additions, with each line performing one action. The structure is flat, with no nesting or branching. Naming is consistent and descriptive, making the intent clear. However, the repetition of `testSuite.addTestSuite(...)` is slightly verbose and could be reduced with a loop or helper method, but the explicit listing aids readability by making each test case visible.
Run 3
The code is highly readable due to its flat, linear structure with no nesting. Each line performs a single, clear action: registering a test suite. The intent is unambiguous, and the test class names are descriptive, aiding comprehension. The sequence follows a logical progression from setup (AddPortlet, AddCategory) through message creation to search and view tests. While repetitive, the repetition is consistent and appropriate for a test registration block. Minor deductions for slight verbosity, but overall the code is concise, well-organized, and easy to scan.
Run 1
Code Structure: A straightforward sequence of test-suite registrations is logically organized. Nesting: No nesting makes the snippet easy to scan. Clarity of intent: addTestSuite and descriptive class names clearly communicate the purpose, though abbreviations such as MB require domain familiarity. Code length: Ten concise statements are appropriate; repetition is useful for explicitly listing tests. Action granularity: Each line performs exactly one registration. Reading flow: The progression from setup and message additions to tag searching and viewing is natural and consistent.
Run 2
Code Structure: A straightforward sequence of related test-suite registrations, logically ordered from setup and message creation to searching and viewing tags. Nesting: Completely flat, with no branching or nested blocks. Clarity of intent: addTestSuite and the test class names clearly communicate registration, though abbreviations such as MB and numeric naming slightly reduce clarity. Code length: Short and appropriately explicit; repetition is reasonable for this small list. Action granularity: Each line performs exactly one registration. Reading flow: Consistent formatting and repeated syntax make the code easy to scan, although spacing between setup, message, and tag tests could better highlight the logical groups.
Run 3
Code Structure: A straightforward sequence of related test-suite registrations, logically grouped. Nesting: Flat, with no nested control flow. Clarity of intent: addTestSuite clearly communicates the purpose, though abbreviations such as MB and numbered test names require domain context. Code length: Concise for explicitly registering ten suites; repetition is appropriate and easy to scan. Action granularity: Each line performs exactly one registration. Reading flow: Consistent formatting and ordering from setup and message creation to tag searching and viewing provide a natural progression.