Sample
Schnappinger/junit4/org.junit.experimental.theories.internal.AllMembersSupplier
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 21.7Δ 10.9 |
| Scalabrino | 0.469 | 0–1; higher is more readable | 6.5Δ 26.2 |
| Dorn | 0.113 | 0–1; higher is more readable | 35.0Δ 2.3 |
| Mi | 0.067 | 0–1; higher is more readable | 7.9Δ 24.8 |
| LLOC | 91 | Logical lines; fewer is more readable | 26.2Δ 6.4 |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs | 38.0Δ 5.3 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 6.3 |
| BTTF | 0.369 | 0–1; higher is more readable | 30.7Δ 2.0 |
| Human | 3.17 | 1–4; original rating | 32.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. | 8920.529 | −294.377 |
| Source linesThe number of non-empty source lines. | 204 | +81.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. | 4.524 | −6.787 |
Intercept 8.87 + feature contributions = -210.694 (log-odds).
Score = sigmoid(-210.694) = 0.
| Score | 0.469 |
|---|
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. | 204 | −6.187 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 200 | +6.181 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 200 | −4.169 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 202.906 | +2.426 |
| 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. | 126.951 | −1.712 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 126.961 | +1.244 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.088 | +0.09 |
Intercept 0.07 + feature contributions = -2.056 (log-odds).
Score = sigmoid(-2.056) = 0.113.
| Score | 0.067 |
|---|
| Score | 91 |
|---|
Run 1
The code is generally well-structured with clear method separation and descriptive naming. The class has a single responsibility (supplying theory parameters), and methods break down the work into logical steps (single/multi point fields/methods). Nesting is mostly shallow, though the MethodParameterValue.getValue() method has a deep try-catch chain. Intent is mostly clear, but some methods like isAssignableToAnyOf could benefit from a brief comment explaining its purpose. Code length is appropriate—not excessively long, though addMultiPointMethods is somewhat dense. Action granularity is good, with one logical operation per line in most places. Reading flow is natural, but the getValue() method's multiple catch blocks interrupt flow slightly. Minor issues: repeated conversion of FrameworkField to Field could be extracted, and the isAssignableToAnyOf method checking type against target.getClass() could be clearer with better parameter naming. Overall, the code is readable but has a few areas for improvement.
Run 2
The code demonstrates good readability with clear method names and logical organization. The class has a single responsibility of supplying theory parameters, and methods are well-named (e.g., addSinglePointFields, addMultiPointMethods). The structure is flat with minimal nesting, and each method focuses on one action. The reading flow is natural, progressing from public interface methods to private helpers. The try-catch blocks are reasonable but include some nested exception handling that slightly increases complexity, especially in MethodParameterValue.getValue(). Some methods like addMultiPointMethods contain conditional logic that could be extracted for even better clarity. The code is concise without being overly compressed, though some exception messages and the isAssignableToAnyOf method could benefit from more context. Overall, the code is quite readable with clear intent and good separation of concerns, with minor opportunities for improvement in exception handling decomposition and reducing a few method lengths.
Run 3
The code is generally well-structured with clear method separation for different data point types (single/multi-point fields/methods). Naming is descriptive but some methods have redundant parameter passing (e.g., 'sig' ignored in several getter methods). The main issue is long lines exceeding reasonable width and some complex conditional logic in addMultiPointMethods. The MethodParameterValue inner class has acceptable single-responsibility design, though its getValue() method contains multiple exception handling branches. Reading flow is natural with logical progression from public API to private helpers. The code would benefit from extracting the multi-point method logic into smaller pieces and removing unused parameters to improve clarity.
Run 1
Code Structure: Well decomposed into focused helpers for fields, methods, arrays, and iterables, with some duplicated field-conversion logic. Nesting: Generally shallow, although addMultiPointMethods combines a loop, conditional, try/catch, and exception filtering. Clarity of intent: Descriptive method names and the class documentation explain the purpose; abbreviated names such as sig, list, and fClass, unused signature parameters, and subtle exception behavior reduce clarity. Code length: Mostly proportionate to the task, but repetitive helpers and verbose reflection error handling add bulk. Action granularity: Statements generally perform one action per line; a few nested calls and compound conditions require extra parsing. Reading flow: getValueSources provides a clear overview, followed by implementation helpers, although helper ordering does not exactly match invocation order and formatting is slightly inconsistent.
Run 2
Code Structure: Well organized into focused helpers for fields, methods, arrays, and iterables, with a clear orchestration method. Nesting: Mostly shallow, but addMultiPointMethods combines a loop, conditional, try/catch, and exception filtering, increasing cognitive load. Clarity of intent: Descriptive method names and annotations communicate the purpose; abbreviated names such as sig, legacy f-prefixed fields, and subtle exception-driven behavior reduce clarity. Code length: Generally appropriate, though duplicated field-conversion routines and similar collection-processing logic add repetition. Action granularity: Most statements perform one action, but nested calls and compound conditions occasionally pack several concepts together. Reading flow: The main workflow reads naturally and helper boundaries support navigation, although helper ordering differs from call ordering, long signatures interrupt scanning, and the early return in exception handling requires careful interpretation.
Run 3
Code Structure: Well decomposed into focused helpers for fields, methods, arrays, and iterables, with some duplicated field-conversion logic. Nesting: Generally shallow, although addMultiPointMethods combines a loop, conditional, try/catch, and exception filtering. Clarity of intent: Descriptive method names and the class comment explain the purpose; abbreviated variables, legacy f-prefixed fields, unused signature parameters, and subtle exception-driven control flow reduce clarity. Code length: Reasonably concise for its responsibilities, but repeated collection conversion and exception handling add verbosity. Action granularity: Most lines perform a single action; a few compound conditions and nested calls require extra parsing. Reading flow: getValueSources provides a clear high-level sequence, followed by implementation helpers. Long signatures, inconsistent formatting, and the early return when an exception is ignored slightly interrupt that flow.