Source code
package def.dom;
@jsweet.lang.Extends({SVGURIReference.class})
public class SVGTextPathElement extends SVGTextContentElement {
public SVGAnimatedEnumeration method;
public SVGAnimatedEnumeration spacing;
public SVGAnimatedLength startOffset;
public double TEXTPATH_METHODTYPE_ALIGN;
public double TEXTPATH_METHODTYPE_STRETCH;
public double TEXTPATH_METHODTYPE_UNKNOWN;
public double TEXTPATH_SPACINGTYPE_AUTO;
public double TEXTPATH_SPACINGTYPE_EXACT;
public double TEXTPATH_SPACINGTYPE_UNKNOWN;
native public void addEventListener(String type, EventListener listener, Boolean useCapture);
public static SVGTextPathElement prototype;
public SVGTextPathElement(){}
public SVGAnimatedString href;
native public void addEventListener(String type, EventListener listener);
native public void addEventListener(String type, EventListenerObject listener, Boolean useCapture);
native public void addEventListener(String type, EventListenerObject listener);
}
Run 1
The code is a straightforward DOM interface definition with a flat structure and minimal nesting, which supports readability. However, its clarity of intent suffers from a lack of comments or documentation explaining the purpose of fields and constants. Action granularity is mostly one declaration per line, which is good, but the grouping of native methods and fields feels somewhat disorganized—fields are interspersed with methods, and constants appear before related instance fields. The reading flow is disrupted by the placement of the static field and constructor amid instance members. Code length is appropriate for the interface, but unnecessary repetition of overlapping method overloads slightly reduces conciseness. Overall, it is readable for a developer familiar with DOM APIs, but could be improved with better organization and explanatory comments.
Run 2
The code is highly unreadable due to poor structure, lack of logical grouping, and ambiguous naming. Fields and methods are mixed without clear separation, making the class appear as a flat, disorganized list. The multiple overloaded `addEventListener` methods are scattered rather than grouped together, and the constructor is placed awkwardly between fields and methods. Naming like `method` and `spacing` is unclear, and numeric constants are declared as `double` when they likely represent enum-like values, reducing clarity. The class is not excessively long, but the lack of organization and comments makes intent difficult to discern. Reading flow is jarring because related elements are not adjacent. Overall, the code requires significant mental effort to understand its purpose and structure.
Run 3
The code is a straightforward Java class declaration, but its readability is undermined by inconsistencies and violations of typical Java conventions. Public fields are scattered with no logical grouping, mixing methods, constants, and instance variables. The single-line method declarations reduce visual clarity and make scanning harder. Naming conventions are inconsistent: constants like 'TEXTPATH_METHODTYPE_ALIGN' should be static final but are declared as mutable public doubles, and fields like 'method' and 'prototype' lack descriptive names. Multiple overloaded native methods are reasonable but would benefit from grouping and line breaks. The constructor and static prototype are placed awkwardly among instance members. Overall, the structure feels disorganized, with poor separation of concerns and a lack of clear intent, making it harder to understand than necessary for such a simple class.
Run 1
Code Structure: The class is simple, but related declarations are scattered: href is separated from other animated properties, and event-listener overloads are interrupted by prototype and the constructor. Nesting: Essentially flat, with no complex control flow. Clarity of intent: Descriptive SVG names and inheritance make its role as an API binding clear, although native methods and public constant-like fields lack explanatory context. Code length: Concise, with little unnecessary content. Action granularity: Each field or method declaration occupies its own line; the empty constructor is compact without obscuring behavior. Reading flow: Generally straightforward, but absent blank-line grouping, inconsistent declaration ordering, and unconventional 'native public' modifier ordering reduce polish.
Run 2
Code Structure: A straightforward class declaration, but fields, constructor, and event-listener overloads are interleaved rather than grouped consistently. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, inheritance, and typed SVG properties clearly indicate a DOM binding; the annotation and prototype field require framework familiarity. Code length: Concise, with no unnecessary implementation logic. Action granularity: Each declaration occupies its own line, although the empty constructor has cramped formatting. Reading flow: Mostly natural, but separating one addEventListener overload from the others and placing href after the constructor disrupts the flow. Logical grouping and modest whitespace would improve readability.
Run 3
Code Structure: The class is logically organized as a compact DOM binding, but related fields and addEventListener overloads are separated by the prototype and constructor. Nesting: Minimal nesting makes scanning easy. Clarity of intent: Descriptive SVG types, field names, and method signatures communicate purpose, though the binding-specific annotation and prototype require familiarity with JSweet. Code length: Concise, with no unnecessary implementation or repetition beyond API overloads. Action granularity: Each declaration occupies its own line, except the compact empty constructor, which remains understandable. Reading flow: Mostly natural, but grouping all fields together and placing the listener overloads consecutively would improve flow. Blank lines between sections and conventional modifier ordering would improve readability.