Sample

Schnappinger/argoUML/org.argouml.uml.ui.foundation.core.UMLAssociationEndOrderingCheckBox

Human rating uses the original dataset scale.

Human3.95
Lines71

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.9990–1; higher is more readable
91.3Δ 21.8
Scalabrino0.760–1; higher is more readable
52.1Δ 17.4
Dorn0.6460–1; higher is more readable
70.6Δ 1.2
Mi0.550–1; higher is more readable
41.6Δ 27.9
LLOC5Logical lines; fewer is more readable
83.0Δ 13.5
DeepSeek V4 Pro170–20; mean of three runs
66.8Δ 2.6
GPT-6.1 Sol170–20; mean of three runs
55.3Δ 14.2
BTTF0.7910–1; higher is more readable
95.0Δ 25.6
Human3.951–4; original rating
69.5

Views

Source code

/* $Id: UMLAssociationEndOrderingCheckBox.java 17897 2010-01-12 21:36:40Z linus $ ***************************************************************************** * Copyright (c) 2009 Contributors - see below * All rights reserved. This program and the accompanying materials * are made available under the terms of the Eclipse Public License v1.0 * which accompanies this distribution, and is available at * http://www.eclipse.org/legal/epl-v10.html * * Contributors: * tfmorris ***************************************************************************** * * Some portions of this file was previously release using the BSD License: */ // Copyright (c) 1996-2006 The Regents of the University of California. All // Rights Reserved. Permission to use, copy, modify, and distribute this // software and its documentation without fee, and without a written // agreement is hereby granted, provided that the above copyright notice // and this paragraph appear in all copies. This software program and // documentation are copyrighted by The Regents of the University of // California. The software program and documentation are supplied "AS // IS", without any accompanying services from The Regents. The Regents // does not warrant that the operation of the program will be // uninterrupted or error-free. The end-user understands that the program // was developed for research purposes and is advised not to rely // exclusively on the program for any reason. IN NO EVENT SHALL THE // UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, // SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, // ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF // THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF // SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY // WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF // MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE // PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF // CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, // UPDATES, ENHANCEMENTS, OR MODIFICATIONS. package org.argouml.uml.ui.foundation.core; import org.argouml.i18n.Translator; import org.argouml.model.Model; import org.argouml.uml.ui.UMLCheckBox2; /** * * @author jaap.branderhorst@xs4all.nl * @since Jan 4, 2003 */ public class UMLAssociationEndOrderingCheckBox extends UMLCheckBox2 { /** * Constructor for UMLAssociationEndOrderingCheckBox. */ public UMLAssociationEndOrderingCheckBox() { super(Translator.localize("label.ordered"), ActionSetAssociationEndOrdering.getInstance(), "ordering"); } /* * @see org.argouml.uml.ui.UMLCheckBox2#buildModel() */ public void buildModel() { if (getTarget() != null) { Object associationEnd = getTarget(); setSelected( Model.getOrderingKind().getOrdered().equals( Model.getFacade().getOrdering(associationEnd))); } } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.71+28.4
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.680.99−22.473
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.219−7.828

Intercept 8.87 + feature contributions = 6.969 (log-odds).
Score = sigmoid(6.969) = 0.999.

Score0.76

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.72−1.513
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.023+0.721
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.70.768+0.579
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.80.833+0.5
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.80.958+0.236
Indentation frequencyHow rapidly indentation changes from line to line.28+0.231
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.28−0.222

Intercept 0.07 + feature contributions = 0.603 (log-odds).
Score = sigmoid(0.603) = 0.646.

Score0.55
Score5
Run 1

The code is highly readable. The structure is logical, with a clear package declaration, imports, class definition, and constructor. Nesting is minimal—only one conditional block exists, and it is flat and easy to follow. The intent is clear: a specialized checkbox for UML association end ordering. Code length is concise and appropriate; the lengthy comments are standard license headers, not functional clutter. Each action is on its own line, and the buildModel method is a short sequence of straightforward calls. The reading flow is natural, moving from constructor setup to behavior. Minor deductions: the license headers are verbose, and the method call chain in setSelected slightly reduces readability, but overall the code is maintainable and clear.

Run 2

The code is generally readable due to its clear structure and intent. The class has a single responsibility, with a short constructor and one overridden method. Nesting is minimal (one if statement), and action granularity is acceptable, though the buildModel method contains a multi-line conditional expression that could be simplified for better clarity. The lengthy copyright headers (over 40 lines) significantly detract from readability, obscuring the actual code at the top of the file. Reading flow is natural for a small class, but the heavy comment block disrupts initial navigation. Overall, the logic is straightforward, but the verbosity of legal text and the slightly dense conditional reduce the score.

Run 3

The code is highly readable due to its clear structure, minimal nesting, and concise implementation. The class has a single responsibility, with a straightforward constructor that delegates localization and action setup. The `buildModel` method uses one level of nesting with a null guard, making the logic easy to follow. Each line performs a single action, and method names clearly convey intent. Imports are minimal and focused. The only minor drawbacks are the extensive license header comments, which add length but are typical for open-source projects, and the slightly verbose chained method call in `setSelected`, though it remains understandable. Overall, the code follows clean coding practices and is easy to read.

Run 1

Code Structure: The class is logically organized with imports, a constructor, and a single model-update method. Nesting: Control flow is shallow, with only one null-check conditional, though nested method calls add visual complexity. Clarity of intent: Descriptive class and variable names make the ordered-association checkbox purpose clear; framework dependencies and minimal behavioral documentation require some external knowledge. Code length: Executable code is concise, but extensive license headers dominate the file and delay reaching the implementation. Action granularity: Statements generally perform one action each, with the selection update expressed as one compound calculation. Reading flow: Conventional Java layout supports natural reading, although the heavily wrapped setSelected expression slightly interrupts it.

Run 2

Code Structure: A small, logically organized class separates initialization from model synchronization. Nesting: Only one conditional introduces control-flow nesting, although the nested method calls require some parsing. Clarity of intent: The class name, ordering label, associationEnd variable, and setSelected call clearly indicate the checkbox's purpose; the minimal documentation does not explain its behavior when the target is null. Code length: Executable code is concise, but extensive licensing comments and boilerplate dominate the file. Action granularity: Statements generally perform one action each; the selection expression combines several lookups but remains manageable. Reading flow: Conventional package/import/class ordering and consistent formatting support natural reading, slightly interrupted by the long header and multiline call chain.

Run 3

Code Structure: The class is logically organized, with imports, a constructor, and a focused model-update method. Nesting: Control flow is shallow, containing only one null-check, though the nested method calls require some parsing. Clarity of intent: The class name, ordering label, and setSelected call clearly indicate an ordering checkbox; buildModel and generic Object typing provide less explicit context. Code length: Executable code is concise, but extensive license text and minimally informative documentation increase reading overhead. Action granularity: Each statement performs one primary action, with the selection calculation embedded in a single expression. Reading flow: Conventional Java layout and consistent indentation support natural reading, although the wrapped call chain slightly interrupts it.