Source code
public class SWTSkinPropertiesImpl
extends SkinPropertiesImpl
implements SWTSkinProperties
{
private static Map colorMap = new LightHashMap();
/**
* @param skinPath
* @param mainSkinFile
*/
public SWTSkinPropertiesImpl(ClassLoader classLoader, String skinPath, String mainSkinFile) {
super(classLoader, skinPath, mainSkinFile);
}
/**
*
*/
public SWTSkinPropertiesImpl() {
super();
}
// @see com.aelitis.azureus.ui.swt.skin.SWTSkinProperties#getColor(java.lang.String)
public Color getColor(String sID) {
Color color;
if (colorMap.containsKey(sID)) {
return (Color) colorMap.get(sID);
}
try {
int[] rgb = getColorValue(sID);
if (rgb[0] > -1) {
color = ColorCache.getColor(Utils.getDisplay(), rgb[0], rgb[1], rgb[2]);
} else {
color = ColorCache.getColor(Utils.getDisplay(), getStringValue(sID));
}
} catch (Exception e) {
// IMP.getLogger().log(LoggerChannel.LT_ERROR,
// "Failed loading color : color." + colorNames[i]);
color = null;
}
colorMap.put(sID, color);
return color;
}
public void clearCache() {
super.clearCache();
colorMap.clear();
}
Run 1
The code is generally readable with clear intent and logical structure. The class extends and implements appropriately, and method names are descriptive. Nesting is shallow (one level inside try/catch), and each action is on its own line. The getColor method has a minor issue: it caches null values, potentially causing repeated failed lookups. The empty comment block and single-line comment add noise. The colorMap is a raw type, losing type safety, and no synchronization is shown despite potential multi-threaded use. The structure follows a natural flow, but the code could be more concise by extracting caching logic. Overall, it's readable but has some maintainability concerns.
Run 2
The code is moderately readable with a clear overall structure and straightforward methods. It benefits from short method bodies and basic Javadoc comments. However, it has several issues: use of raw Map type (no generics), an unnecessary initial color assignment, potential null pointer risk when rgb array is empty, and a null value is stored in the colorMap if an exception occurs, which can lead to confusing behavior. The getColor method mixes caching logic with exception handling and multiple paths, slightly reducing clarity. Nesting is shallow and actions are mostly one per line, but naming conventions like 'sID' are slightly unclear. Overall, it is understandable but could be improved with generics, null handling, and simpler logic flow.
Run 3
The code is moderately readable but has several issues. Structure is logical (constructor overloads, override, cache clearing) but the colorMap is static and non-generic, weakening type safety and intent. Nesting is acceptable — only one try-catch and one if-else. Clarity of intent is mixed: the method purpose is clear, but the commented-out error handling and magic number `-1` obscure behavior. Code length is reasonable; no obvious bloat. Action granularity is mostly one action per line, though multiple operations occur in the if-else block. Reading flow is natural: check cache, compute color, store and return. Main deductions: raw Map type, unused classLoader parameter, dead commented code, and lack of null-safety for `rgb` array. Overall, understandable but not polished.
Run 1
Code Structure: Methods are logically separated into construction, color retrieval, and cache clearing. Nesting: Shallow conditionals and a single try/catch keep complexity low; the cache-hit early return helps. Clarity of intent: The caching and color-resolution logic are understandable, but sID, the rgb[0] sentinel, a raw Map, and silent exception handling leave details unclear. Code length: Compact overall, although empty Javadocs and commented-out logging add clutter. Action granularity: Statements generally perform one action per line, with readable method calls. Reading flow: Retrieval proceeds naturally from cache lookup to resolution, caching, and return. Inconsistent comment formatting and the missing final class-closing brace slightly detract from presentation.
Run 2
Code Structure: Constructors, color lookup, and cache clearing are logically separated. Nesting: Shallow conditionals and an early cache return keep complexity manageable. Clarity of intent: Method names communicate purpose, but sID, raw Map usage, the rgb[0] sentinel, and silent exception handling obscure details. Code length: The implementation is concise, though empty documentation and commented-out logging add clutter. Action granularity: Most lines perform one action; chained calls in color creation remain understandable. Reading flow: Cache lookup, color resolution, caching, and return follow a natural sequence. Inconsistent formatting and the missing final class-closing brace reduce polish.
Run 3
Code Structure: Constructors, color retrieval, and cache clearing are logically separated, although the snippet lacks a closing class brace. Nesting: An early cache return keeps nesting modest; the try/catch and RGB conditional are easy to follow. Clarity of intent: Method names communicate their purposes, but sID, raw Map usage, the rgb[0] sentinel, and silent exception handling obscure details. Code length: The implementation is concise, though empty documentation and commented-out logging add clutter. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Retrieval proceeds naturally from cache lookup to color resolution, caching, and return; inconsistent formatting and obsolete comments slightly interrupt that flow.