Sample
Schnappinger/argoUML/org.argouml.util.PredicateStringMatch
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 50.5Δ 35.0 |
| Scalabrino | 0.476 | 0–1; higher is more readable | 7.5Δ 77.9 |
| Dorn | 0.509 | 0–1; higher is more readable | 61.4Δ 24.1 |
| Mi | 0.567 | 0–1; higher is more readable | 49.8Δ 35.6 |
| LLOC | 39 | Logical lines; fewer is more readable | 43.9Δ 41.6 |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs | 41.3Δ 44.2 |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs | 30.7Δ 54.8 |
| BTTF | 0.554 | 0–1; higher is more readable | 51.2Δ 34.3 |
| Human | 3.97 | 1–4; original rating | 85.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. | 2224.262 | −73.401 |
| Source linesThe number of non-empty source lines. | 108 | +43.2 |
| 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.01 | −7.514 |
Intercept 8.87 + feature contributions = -28.845 (log-odds).
Score = sigmoid(-28.845) = 0.
| Score | 0.476 |
|---|
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. | 109 | −2.823 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 70 | +1.684 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 70 | −1.185 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 107.797 | +1.097 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.456 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 73.018 | +0.374 |
| 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. | 77.972 | +0.363 |
Intercept 0.07 + feature contributions = 0.035 (log-odds).
Score = sigmoid(0.035) = 0.509.
| Score | 0.567 |
|---|
| Score | 39 |
|---|
Run 1
The code is generally well-structured and readable. The class has a clear purpose as a string-matching predicate, and methods are concise. The `create` factory method uses a flat, if-conditional style with low nesting, and the `evaluate` method has a clear flow: null check, prefix/suffix checks, then a loop. Action granularity is appropriate, mostly one action per line. However, readability is slightly reduced by the long copyright header (not core logic), the use of raw arrays and a separate count (where a collection would be clearer), and the somewhat cryptic `(target + "*").indexOf(pattern)` trick, which works but requires extra thought. Variable names like `pats`, `st`, and `o` are not as descriptive as they could be. Overall, the code is maintainable but could be more self-documenting.
Run 2
The code is logically structured with clear methods and reasonable naming, but readability suffers from several issues. The create() method is relatively flat and each line tends to perform one action, which is good. However, the evaluate() method uses a non-obvious algorithm—appending '*' to the target and repeatedly searching for patterns—making intent difficult to follow. The constructor is protected while create() is static, which may confuse readers about instantiation flow. Long license headers add bulk before the actual code. Pattern matching logic relies on implicit ordering and substring search rather than a straightforward wildcard parser, reducing clarity. Overall, the class is maintainable but requires domain knowledge to fully understand its matching behavior, keeping it from being highly readable.
Run 3
The code is generally well-structured and readable. The class has a clear purpose and follows a logical organization with a constructor, factory method, and evaluation method. Nesting is minimal, with only a single level in the evaluate method. Variable and method names clearly communicate intent. The code is reasonably concise, though the license header adds significant length. Each line performs a single action, contributing to clean granularity. Reading flow is natural, with the factory method handling edge cases before creating instances. Minor deductions: the evaluate method's loop logic is slightly subtle (e.g., appending '*' to target during indexOf), and the constructor is package-private while the factory method is public, which could confuse readers about instantiation intent. Overall, the code is maintainable and understandable.
Run 1
Code Structure: The class is logically organized into state, construction, a factory method, and evaluation. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: The class documentation and method names convey wildcard matching, but empty-string boundary markers, the appended '*' during evaluation, and iterating the entire array rather than patternCount obscure implementation intent. Code length: The implementation is concise; lengthy license notices add visual overhead but are separate from the logic. Action granularity: Most lines perform one action, although pats[count++] combines assignment and counter mutation. Reading flow: Formatting and sequential checks provide a natural progression, but abbreviated names such as pats and st, unexplained MAX_PATS, and the implicit array assumptions require extra interpretation.
Run 2
Code Structure: The class separates predicate creation from evaluation, with logically grouped checks. Nesting: Shallow loops and early returns keep control flow easy to follow. Clarity of intent: The class documentation and method names explain wildcard matching, but abbreviated names such as pats and st, empty-string boundary markers, and the unexplained target + "*" expression obscure details. Iterating over the entire patterns array rather than patternCount also makes the handling of unused entries confusing. Code length: The implementation is compact, although the extensive license header delays access to the relevant code. Action granularity: Most lines perform one action; assignments containing count++ combine storage and counter updates. Reading flow: Creation proceeds naturally from normalization through tokenization to predicate selection, and evaluation proceeds through boundary checks and sequential matching. Overall, readable organization is weakened by implicit matching conventions and unclear array assumptions.
Run 3
Code Structure: Clearly separates pattern construction from evaluation, with logically grouped checks. Nesting: Shallow conditionals and early returns keep control flow simple. Clarity of intent: Class documentation and method names explain wildcard matching, but abbreviated names such as pats and st, empty-string boundary markers, and the unexplained target + "*" expression obscure details. Evaluation iterates over the entire allocated array rather than patternCount, making unused entries confusing and potentially erroneous. Code length: Implementation is compact, although the extensive license header delays reaching the relevant logic. Action granularity: Most lines perform one action; count++ within array assignments slightly combines responsibilities. Reading flow: Formatting and sequential checks are natural, but understanding token handling and destructive target updates requires tracing the algorithm.