Source code
package def.dom;
public class Selection extends def.js.Object {
public Node anchorNode;
public double anchorOffset;
public Node focusNode;
public double focusOffset;
public Boolean isCollapsed;
public double rangeCount;
public String type;
native public void addRange(Range range);
native public void collapse(Node parentNode, double offset);
native public void collapseToEnd();
native public void collapseToStart();
native public Boolean containsNode(Node node, Boolean partlyContained);
native public void deleteFromDocument();
native public void empty();
native public void extend(Node newNode, double offset);
native public Range getRangeAt(double index);
native public void removeAllRanges();
native public void removeRange(Range range);
native public void selectAllChildren(Node parentNode);
native public void setBaseAndExtent(Node baseNode, double baseOffset, Node extentNode, double extentOffset);
native public String toString();
public static Selection prototype;
public Selection(){}
}
Run 1
The code is highly readable. It has a logical structure with clear separation between properties and methods, following a consistent ordering. There is no nesting, as it's a flat class definition. The intent is unambiguous: it implements the DOM Selection interface. The code is concise; each method is declared in a single line, which is appropriate for native bindings. Action granularity is excellent, with one action per line. Reading flow is natural, with related methods grouped together and a familiar naming convention. The only minor drawback is the automatic generation artifact of an empty constructor, but this doesn't significantly impact readability.
Run 2
The code is straightforward and well-structured for a DOM API wrapper. It declares fields before methods, maintains consistent formatting, and uses clear method names that match the underlying Selection API. Nesting is non-existent, and each line represents one declaration or action. The only minor issues are the use of `double` for offsets that are typically integers in JavaScript, and `Boolean` wrapper objects instead of primitives, which could confuse readers unfamiliar with the codebase's conventions. The constructor at the end is slightly out of logical order, but this is a minor structural issue. Overall, the code is highly readable, concise, and unambiguous in its intent.
Run 3
The code demonstrates decent structure with clear separation between fields and methods. It follows Java-like conventions with public fields declared first, then methods, which aids readability. Each declaration is on its own line, maintaining good action granularity. The nesting is completely flat with no conditional blocks or loops, which is appropriate for this type of interface/type definition. Method names are descriptive and follow standard DOM API conventions, making intent clear. However, the code loses points for several reasons: the 'native' keyword without context is ambiguous, there's inconsistent use of wrapper types (Boolean vs double vs String), and no comments or documentation explaining the purpose of the class or its members. While concise, the absence of any explanatory context and the repetitive native method declarations make it feel like boilerplate code rather than thoughtfully designed code.
Run 1
Code Structure: Fields and native methods are logically grouped, although the static prototype field and constructor could be separated more clearly. Nesting: Only a single class scope, making the code easy to scan. Clarity of intent: Familiar DOM Selection terminology and descriptive method and parameter names communicate purpose well; the native-binding context is implicit. Code length: Concise declarations with no unnecessary implementation details. Action granularity: Each field or method declaration occupies its own line. Reading flow: Consistent formatting and related method names support natural reading, though blank lines between sections and conventional modifier ordering would improve presentation.
Run 2
Code Structure: Fields and native methods are logically grouped, though the trailing prototype field and constructor slightly weaken organization. Nesting: Only the class scope is present, making the code easy to scan. Clarity of intent: Descriptive names clearly identify a DOM selection API; native declarations appropriately omit implementations. Code length: Concise, with no unnecessary logic or repetition beyond the required API declarations. Action granularity: Each field or method declaration occupies its own line. Reading flow: Consistent indentation and predictable declarations support natural reading, but blank lines between member groups and conventional 'public native' modifier ordering would improve readability.
Run 3
Code Structure: Clearly organized as a compact API declaration, with fields followed by methods, though the static prototype and constructor placement slightly weaken grouping. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive class, field, and method names make the selection API understandable; native declarations appropriately omit implementation details. Code length: Concise, with little unnecessary content. Action granularity: Each field or method declaration occupies its own line. Reading flow: Consistent indentation and predictable declarations support easy scanning, but blank lines between sections and conventional 'public native' modifier ordering would improve readability.