Sample
Schnappinger/argoUML/org.argouml.uml.diagram.static_structure.layout.ClassdiagramModelElementFactory
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 52.5Δ 16.0 |
| Scalabrino | 0.703 | 0–1; higher is more readable | 38.4Δ 1.9 |
| Dorn | 0.447 | 0–1; higher is more readable | 58.1Δ 21.6 |
| Mi | 0.544 | 0–1; higher is more readable | 40.6Δ 4.1 |
| LLOC | 18 | Logical lines; fewer is more readable | 63.4Δ 26.9 |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs | 47.4Δ 10.9 |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs | 48.0Δ 11.6 |
| BTTF | 0.645 | 0–1; higher is more readable | 66.3Δ 29.9 |
| Human | 3.3 | 1–4; original rating | 36.5 |
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. | 1988.702 | −65.627 |
| Source linesThe number of non-empty source lines. | 96 | +38.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.129 | −7.694 |
Intercept 8.87 + feature contributions = -26.051 (log-odds).
Score = sigmoid(-26.051) = 0.
| Score | 0.703 |
|---|
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. | 97 | −2.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 50 | +0.992 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 95.918 | +0.931 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.876 | +0.742 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 50 | −0.727 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.038 | +0.576 |
| 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. | 95.959 | −0.399 |
Intercept 0.07 + feature contributions = -0.212 (log-odds).
Score = sigmoid(-0.212) = 0.447.
| Score | 0.544 |
|---|
| Score | 18 |
|---|
Run 1
The code is well-structured, with clear class and method organization, appropriate logging, and a singleton pattern. The getInstance method uses a flat if-else chain without deep nesting, making the action granularity and reading flow natural. Each branch has a single purpose, and the code length is concise. The intent is clear: map Fig types to layout objects. Minor deductions occur due to redundant parentheses around 'new' expressions, the misspelled 'Layouter' in comments, and the slightly noisy license header. Overall, readability is high with only trivial style inconsistencies.
Run 2
The code is generally readable with a clear, logical structure. The class has a single responsibility (factory for layout objects) and the getInstance method follows a straightforward if-else chain with one action per branch, keeping nesting flat and intent obvious. Naming is descriptive, and the use of a singleton pattern is explicit. However, readability is slightly reduced by the extensive license header, which pushes the actual code far down. Additionally, inconsistent parenthesization in return statements (some wrapped, some not) and the lack of a default branch (falling through to logging) make the control flow slightly less polished. The method length is acceptable, and the logging message is clear. Overall, it is concise and well-organized, but minor style inconsistencies and verbose header boilerplate prevent a higher score.
Run 3
The code is generally readable with a clear purpose: a factory that maps figure types to layout objects. The structure is logical, with a singleton pattern and a single public method. Nesting is minimal; the method uses a flat if-else chain rather than deep nesting. Clarity of intent is good, though the method name 'getInstance' could be more descriptive. Code length is reasonable. Action granularity is mostly one action per line, though some lines combine casting and constructor calls. Reading flow is natural, starting with imports and class definition, then the method. Minor issues: verbose license header, inconsistent parentheses around return values, and a typo in a comment ('Fig.*'). Overall, it is straightforward factory code that could be improved with a switch or map-based approach and better naming.
Run 1
Code Structure: A small singleton factory with a clearly isolated dispatch method is logically organized. Nesting: The flat if/else-if chain and immediate returns keep nesting shallow. Clarity of intent: Descriptive figure and layout class names make the mappings understandable, but the generic parameter name 'f', broad Object type, and outdated class comment obscure the supported scope. Code length: The implementation is concise, although extensive license headers and redundant parentheses add visual bulk. Action granularity: Each branch performs one straightforward construction and return; logging and fallback are separate statements. Reading flow: Type checks follow a consistent, easy-to-scan pattern, but inconsistent indentation, brace placement, and return formatting slightly disrupt flow. The undocumented assumption that the argument is non-null also makes the fallback behavior less explicit.
Run 2
Code Structure: A small, focused factory with clearly separated singleton initialization and object creation logic. Nesting: The flat if/else-if chain and immediate returns are easy to follow. Clarity of intent: Descriptive class names and explicit type checks make the mappings clear, but the parameter name 'f' is vague, and the class documentation misleadingly claims support only for generalizations and realizations. Code length: The implementation is concise; the lengthy license header adds scrolling but little complexity. Action granularity: Each statement performs one clear action, with no compressed multi-statement lines. Reading flow: Imports, fields, constructor, and factory method follow a natural order. Inconsistent indentation, brace placement, redundant return parentheses, and uneven documentation formatting slightly disrupt readability.
Run 3
Code Structure: The factory is logically organized, with singleton setup followed by one focused dispatch method. Nesting: A shallow if/else-if chain and immediate returns keep complexity low. Clarity of intent: Descriptive class names make the figure-to-layout mappings clear, although the parameter name 'f' is vague and the class comment incorrectly suggests only generalizations and realizations are supported. Code length: The implementation is concise; the lengthy license header adds scanning overhead without complicating the logic. Action granularity: Each branch performs a single construction and return, and logging is separate. Reading flow: The mappings read naturally from top to bottom, followed by an unsupported-type fallback. Inconsistent indentation, brace placement, and redundant parentheses slightly reduce polish.