Sample

Schnappinger/argoUML/org.argouml.uml.diagram.ui.PathConvPercent2

Human rating uses the original dataset scale.

Human3.24
Lines177

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
51.2Δ 17.2
Scalabrino0.780–1; higher is more readable
58.2Δ 24.2
Dorn0.1370–1; higher is more readable
36.3Δ 2.3
Mi0.6110–1; higher is more readable
64.7Δ 30.7
LLOC37Logical lines; fewer is more readable
45.2Δ 11.2
DeepSeek V4 Pro140–20; mean of three runs
29.9Δ 4.1
GPT-6.1 Sol15.330–20; mean of three runs
30.7Δ 3.3
BTTF0.2170–1; higher is more readable
12.5Δ 21.5
Human3.241–4; original rating
34.0

Views

Source code

/* $Id: PathConvPercent2.java 17865 2010-01-12 20:45:26Z 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.diagram.ui; import java.awt.Point; import org.tigris.gef.base.PathConv; import org.tigris.gef.presentation.Fig; /** * Used to place labels as specific positions along a FigEdge. For example, a * label can be placed in the middle of a FigEdge by using 50%. This version * changes the behavior as it tries to avoid that the itemFig cuts through the * pathFig. * * @author abonner@ics.uci.edu */ public class PathConvPercent2 extends PathConv { /** * The item Fig. */ private Fig itemFig; /** * The percent. */ private int percent; /** * The offset. */ private int offset; /** * Constructor. * * @param theFig The Fig. * @param theItemFig The item Fig. * @param newPercent The percent. * @param newOffset The offset. */ public PathConvPercent2(Fig theFig, Fig theItemFig, int newPercent, int newOffset) { super(theFig); itemFig = theItemFig; setPercentOffset(newPercent, newOffset); } /* * @see org.tigris.gef.base.PathConv#stuffPoint(java.awt.Point) */ public void stuffPoint(Point res) { int figLength = _pathFigure.getPerimeterLength(); if (figLength < 10) { res.setLocation(_pathFigure.getCenter()); return; } int pointToGet = (figLength * percent) / 100; _pathFigure.stuffPointAlongPerimeter(pointToGet, res); applyOffsetAmount(_pathFigure.pointAlongPerimeter(pointToGet + 5), _pathFigure.pointAlongPerimeter(pointToGet - 5), offset, res); } /** * Set the percent and offset again. * * @param newPercent The new percent. * @param newOffset The new offset. */ public void setPercentOffset(int newPercent, int newOffset) { percent = newPercent; offset = newOffset; } /* * @see org.tigris.gef.base.PathConv#setClosestPoint(java.awt.Point) */ public void setClosestPoint(Point newPoint) { } /* * @see org.tigris.gef.base.PathConv#applyOffsetAmount(java.awt.Point, java.awt.Point, int, java.awt.Point) */ protected void applyOffsetAmount( Point p1, Point p2, int theOffset, Point res) { // slope of the line we're finding the normal to // is slope, and the normal is the negative reciprocal // slope is (p1.y - p2.y) / (p1.x - p2.x) // so recip is - (p1.x - p2.x) / (p1.y - p2.y) int recipnumerator = (p1.x - p2.x) * -1; int recipdenominator = (p1.y - p2.y); if (recipdenominator == 0 && recipnumerator == 0) { return; } // find the point offset on the line that gives a // correct offset double len = Math.sqrt(recipnumerator * recipnumerator + recipdenominator * recipdenominator); int dx = (int) ((recipdenominator * theOffset) / len); int dy = (int) ((recipnumerator * theOffset) / len); res.x += Math.abs(dx); res.y -= Math.abs(dy); int width = itemFig.getWidth() / 2; if (recipnumerator != 0) { double slope = (double) recipdenominator / (double) recipnumerator; double factor = tanh(slope); res.x += (Math.abs(factor) * width); } else { res.x += width; } } /** * Calculate the tangens hyperbolicus. * * @param x The argument. * @return tangens hyberbolicus */ private double tanh(double x) { return ((Math.exp(x) - Math.exp(-x)) / 2) / ((Math.exp(x) + Math.exp(-x)) / 2); } /** * The UID. */ private static final long serialVersionUID = -8079350336685789199L; }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.3049.381−100.63
Source linesThe number of non-empty source lines.177+70.8
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.944−7.416

Intercept 8.87 + feature contributions = -28.375 (log-odds).
Score = sigmoid(-28.375) = 0.

Score0.78

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.178−5.266
Indentation frequencyHow rapidly indentation changes from line to line.98+2.653
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.176.866+2.062
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.98−1.828
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.110.994−1.036
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.110.399+0.977
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.042+0.53

Intercept 0.07 + feature contributions = -1.839 (log-odds).
Score = sigmoid(-1.839) = 0.137.

Score0.611
Score37
Run 1

The code is generally clear and well-documented, with a logical class structure and meaningful method/field names. However, readability suffers in `applyOffsetAmount` due to low-level math logic with cryptic comments, variables like `recipnumerator`/`recipdenominator`, and a redundant `tanh` calculation that obscures intent. `stuffPoint` uses magic numbers (10, 5, 100) without explanation. The license header adds noise, and `setClosestPoint` is empty with no clarification. Nesting is shallow but the math-heavy method creates a cognitive load. Line-level clarity is decent, but some lines bundle multiple operations. The class is concise overall but could be improved by extracting the offset logic into a well-named helper and explaining the geometric intent more clearly.

Run 2

The code has decent structure with clear class organization and reasonable Javadoc comments, but suffers from readability issues. The method 'applyOffsetAmount' contains complex mathematical logic with comments explaining the math but using unclear variable names like 'recipnumerator' and 'recipdenominator'. The overall nesting is acceptable, but the mathematical operations make intent hard to follow. Code length is reasonable, though the custom 'tanh' implementation is unnecessarily verbose. Action granularity is mostly one action per line, but some complex expressions combine multiple operations. Reading flow is disrupted by the mathematical calculations and inline math comments that don't clearly explain the geometric purpose. The unused 'setClosestPoint' method and serialVersionUID add noise. While the basic structure and naming conventions are adequate, the mathematical complexity and unclear variable names significantly reduce clarity.

Run 3

The code is generally structured and readable, with appropriate class and method organization. However, it suffers from several issues: outdated Javadoc comments, unnecessary serialVersionUID placement, magic numbers (10, 5, 100), and a complex mathematical offset calculation in applyOffsetAmount that lacks sufficient clarity. While methods are logically separated and nested depth is acceptable, the reading flow is interrupted by verbose comments and unclear variable names like recipnumerator. The empty setClosestPoint method is a code smell. Despite these issues, the code maintains a reasonable action granularity and overall intent is discernible, earning a moderate score.

Run 1

Code Structure: The class is logically organized into state, construction, positioning, and mathematical helpers, though the empty setClosestPoint method lacks explanation. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: The class documentation explains label placement, but terse names such as res, p1, and p2, unexplained constants (10 and 5), and the geometric offset calculations require interpretation. Comments explain the normal calculation but not the rationale for absolute offsets or the tanh adjustment. Code length: Methods are reasonably concise, although repetitive boilerplate documentation and the lengthy license header increase scanning effort. Action granularity: Statements generally perform one action per line, with calculations separated into intermediate variables. Reading flow: Execution proceeds naturally from perimeter positioning to offset adjustment, but inconsistent line wrapping, redundant parentheses, and awkward mathematical variable names interrupt readability.

Run 2

Code Structure: Logically organized into focused methods for positioning, configuration, and offset calculation. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Class documentation explains the purpose, and mathematical comments help, but names such as stuffPoint, res, and recipnumerator require interpretation. The unexplained constants 10 and 5, absolute-value adjustments, and empty setClosestPoint method obscure some decisions. Code length: Implementation is reasonably concise, although extensive licensing text and repetitive, low-information Javadoc add reading overhead. Action granularity: Statements generally perform one action per line; mathematical expressions remain manageable. Reading flow: Consistent formatting and sequential calculations support natural reading, but unusual line wrapping and the geometry-specific offset logic require extra attention.

Run 3

Code Structure: Clearly organized into focused methods, with positioning and offset calculations separated. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Class documentation explains label placement, and comments explain the normal-vector calculation, but names such as res, p1, and recipnumerator require interpretation. Magic constants 10 and 5, unexplained absolute-value adjustments, and an undocumented empty method obscure some behavior. Code length: Implementation is reasonably concise, although extensive boilerplate documentation and the manual tanh formula add reading overhead. Action granularity: Statements generally perform one action per line, making updates easy to track. Reading flow: Methods proceed logically from selecting a point to applying offsets, but inconsistent wrapping and dense geometric arithmetic interrupt the otherwise natural flow.