Sample

Schnappinger/jsweet/org.jsweet.transpiler.GlobalBeforeTranslationScanner

Human rating uses the original dataset scale.

Human1
Lines197

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
19.7Δ 19.4
Scalabrino0.3680–1; higher is more readable
3.4Δ 3.1
Dorn0.110–1; higher is more readable
34.7Δ 34.3
Mi0.6280–1; higher is more readable
68.0Δ 67.7
LLOC70Logical lines; fewer is more readable
29.7Δ 29.4
DeepSeek V4 Pro12.670–20; mean of three runs
18.8Δ 18.5
GPT-6.1 Sol130–20; mean of three runs
9.4Δ 9.1
BTTF0.2260–1; higher is more readable
14.2Δ 13.9
Human11–4; original rating
0.3

Views

Source code

/* * JSweet transpiler - http://www.jsweet.org * Copyright (C) 2015 CINCHEO SAS <renaud.pawlak@cincheo.fr> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software Foundation, * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */ package org.jsweet.transpiler; import java.util.HashSet; import java.util.List; import java.util.Set; import javax.lang.model.element.ElementKind; import javax.lang.model.element.Modifier; import javax.lang.model.element.TypeElement; import javax.lang.model.type.TypeMirror; import org.jsweet.JSweetConfig; import org.jsweet.transpiler.util.AbstractTreeScanner; import org.jsweet.transpiler.util.Util; import com.sun.tools.javac.code.Symbol; import com.sun.tools.javac.code.Symbol.ClassSymbol; import com.sun.tools.javac.code.Symbol.MethodSymbol; import com.sun.tools.javac.code.Symbol.VarSymbol; import com.sun.tools.javac.code.Type; import com.sun.tools.javac.tree.JCTree; import com.sun.tools.javac.tree.JCTree.JCBlock; import com.sun.tools.javac.tree.JCTree.JCClassDecl; import com.sun.tools.javac.tree.JCTree.JCCompilationUnit; import com.sun.tools.javac.tree.JCTree.JCLiteral; import com.sun.tools.javac.tree.JCTree.JCMethodDecl; import com.sun.tools.javac.tree.JCTree.JCVariableDecl; import com.sun.tools.javac.tree.JCTree.JCWildcard; /** * This AST scanner performs global analysis and fills up the context with * information that will be used by the translator. * * @see JSweetContext * @author Renaud Pawlak */ public class GlobalBeforeTranslationScanner extends AbstractTreeScanner { Set<JCVariableDecl> lazyInitializedStaticCandidates = new HashSet<>(); /** * Creates a new global scanner. */ public GlobalBeforeTranslationScanner(TranspilationHandler logHandler, JSweetContext context) { super(logHandler, context, null); } @Override public void visitTopLevel(JCCompilationUnit topLevel) { if (topLevel.packge.getQualifiedName().toString().startsWith(JSweetConfig.LIBS_PACKAGE + ".")) { return; } this.compilationUnit = topLevel; super.visitTopLevel(topLevel); } @Override public void visitClassDef(JCClassDecl classdecl) { if (getCompilationUnit().docComments.hasComment(classdecl)) { context.docComments.put(classdecl.sym, getCompilationUnit().docComments.getCommentText(classdecl)); } TypeMirror superClassType = context.modelTypes.erasure(((TypeElement) classdecl.sym).getSuperclass()); if (superClassType.toString().startsWith("java.") && !superClassType.toString().equals(Object.class.getName()) && !context.types.isSubtype(classdecl.type, context.symtab.throwableType) && !Util.isSourceElement(context.modelTypes.asElement(superClassType))) { // the class extends a JDK class context.addJdkSubclass(classdecl.sym.toString(), superClassType); } if (classdecl.sym.getEnclosingElement() instanceof ClassSymbol) { Type superClass = ((ClassSymbol) classdecl.sym.getEnclosingElement()).getSuperclass(); if (superClass != null && superClass.tsym != null) { ClassSymbol clashingInnerClass = Util.findInnerClassDeclaration((ClassSymbol) superClass.tsym, classdecl.name.toString()); if (clashingInnerClass != null && !context.hasClassNameMapping(clashingInnerClass)) { context.addClassNameMapping(classdecl.sym, "__" + classdecl.sym.getEnclosingElement().getQualifiedName().toString().replace('.', '_') + "_" + clashingInnerClass.getSimpleName()); } } } else { if (classdecl.sym.getKind() == ElementKind.ANNOTATION_TYPE && context.hasAnnotationType(classdecl.sym, JSweetConfig.ANNOTATION_DECORATOR)) { context.registerDecoratorAnnotation(classdecl); } } boolean globals = false; if (JSweetConfig.GLOBALS_CLASS_NAME.equals(classdecl.name.toString())) { globals = true; } for (JCTree def : classdecl.defs) { if (def instanceof JCVariableDecl) { JCVariableDecl var = (JCVariableDecl) def; if (getCompilationUnit().docComments.hasComment(var)) { context.docComments.put(var.sym, getCompilationUnit().docComments.getCommentText(var)); } if (!context.hasFieldNameMapping(var.sym)) { VarSymbol clashingField = null; clashingField = Util.findFieldDeclaration((ClassSymbol) classdecl.sym.getSuperclass().tsym, var.name); if (clashingField != null) { if (clashingField.isPrivate() && !context.hasFieldNameMapping(clashingField)) { context.addFieldNameMapping(var.sym, JSweetConfig.FIELD_METHOD_CLASH_RESOLVER_PREFIX + classdecl.sym.toString().replace(".", "_") + "_" + var.name.toString()); } } MethodSymbol m = Util.findMethodDeclarationInType(context.types, classdecl.sym, var.name.toString(), null); if (m != null) { context.addFieldNameMapping(var.sym, JSweetConfig.FIELD_METHOD_CLASH_RESOLVER_PREFIX + var.name.toString()); } } if (var.getModifiers().getFlags().contains(Modifier.STATIC)) { if (!(var.getModifiers().getFlags().contains(Modifier.FINAL) && var.init != null && var.init instanceof JCLiteral)) { lazyInitializedStaticCandidates.add(var); } } } else if (def instanceof JCBlock) { if (((JCBlock) def).isStatic()) { context.countStaticInitializer(classdecl.sym); } } if (globals && def instanceof JCMethodDecl) { if (((JCMethodDecl) def).sym.isStatic()) { context.registerGlobalMethod(classdecl, (JCMethodDecl) def); } } } super.visitClassDef(classdecl); } @Override public void visitMethodDef(JCMethodDecl methodDecl) { if (getCompilationUnit().docComments.hasComment(methodDecl)) { context.docComments.put(methodDecl.sym, getCompilationUnit().docComments.getCommentText(methodDecl)); } if (methodDecl.mods.getFlags().contains(Modifier.DEFAULT)) { getContext().addDefaultMethod(compilationUnit, getParent(JCClassDecl.class), methodDecl); } if (!getContext().ignoreWildcardBounds) { scan(methodDecl.params); } } @Override public void visitWildcard(JCWildcard wildcard) { Symbol container = null; JCMethodDecl method = getParent(JCMethodDecl.class); if (method != null) { container = method.sym; } if (container != null) { getContext().registerWildcard(container, wildcard); scan(wildcard.getBound()); } } public void process(List<JCCompilationUnit> compilationUnits) { for (JCCompilationUnit compilationUnit : compilationUnits) { scan(compilationUnit); } for (JCVariableDecl var : lazyInitializedStaticCandidates) { if (context.getStaticInitializerCount(var.sym.enclClass()) == 0 && var.init == null || Util.isLiteralExpression(var.init)) { continue; } context.lazyInitializedStatics.add(var.sym); } } }

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.10080.7−332.663
Source linesThe number of non-empty source lines.197+78.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.5.208−7.813

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

Score0.368

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.198−5.974
Indentation frequencyHow rapidly indentation changes from line to line.171+5.178
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.171−3.503
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.196.929+2.343
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.111.98−1.078
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.111.985+1.002
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.11−0.125

Intercept 0.07 + feature contributions = -2.087 (log-odds).
Score = sigmoid(-2.087) = 0.11.

Score0.628
Score70
Run 1

The code has some structural organization but suffers from several readability issues. The visitClassDef method is excessively long (50+ lines) and performs multiple unrelated operations: documentation processing, superclass analysis, inner class clash resolution, decorator registration, globals handling, and field analysis. This violates single responsibility and makes the method's purpose unclear. Nesting reaches 4-5 levels in places, making the logic hard to follow. Several lines combine multiple operations (e.g., checking multiple conditions with &&). Variable names are generally clear but some are cryptic (e.g., 'm', 'var'). The process method has complex boolean logic that is difficult to parse. While the code follows consistent formatting and has helpful comments, the dense, monolithic structure significantly impairs readability and maintainability.

Run 2

The code is generally well-structured and readable, with clear separation of concerns and descriptive method names. The class follows a logical flow: each visitor method handles a specific AST node type. However, readability suffers from several issues. The visitClassDef method is quite long (over 60 lines) and accumulates multiple responsibilities: documentation handling, class hierarchy analysis, inner class clash detection, field clash detection, static initialization tracking, and global method registration. Some deeply nested conditions appear, particularly in the field clash detection logic and the inner class handling, making the control flow harder to follow at a glance. Long qualified expressions and chained method calls (e.g., getEnclosingElement().getQualifiedName().toString().replace(...)) reduce readability. The lazyIn initializedStaticCandidates logic in process() uses a complex boolean condition that could be extracted for clarity. Minor positive aspects include consistent naming, useful comments, and one-action-per-line formatting in most places.

Run 3

The code has a clear structure with logical class organization and appropriate Javadoc comments. Imports are well-organized and the class purpose is evident. However, readability is hindered by several factors: long methods (visitClassDef is ~60 lines), multiple nested conditionals, and complex boolean expressions. Several lines contain multiple actions, such as the chained method calls in the clashingInnerClass mapping. The condition `context.getStaticInitializerCount(var.sym.enclClass()) == 0 && var.init == null || Util.isLiteralExpression(var.init)` lacks parentheses, making intent ambiguous. Variable names like 'm', 'var', and 'def' are somewhat generic. The code mixes different concerns within visitClassDef (doc comments, JDK subclass detection, inner class clashes, field mappings, static initializers), reducing clarity. While it follows standard Java patterns and uses descriptive method names overall, the density of logic and lack of helper method extraction for distinct blocks make it moderately difficult to follow.

Run 1

Code Structure: Visitor overrides logically organize analysis by AST node, but visitClassDef combines several responsibilities that would benefit from helper methods. Nesting: Field processing reaches roughly five nested control levels, making conditions harder to follow. Clarity of intent: Descriptive names, class documentation, and context method names explain most operations; terse variables and the mixed &&/|| condition in process obscure some details. Code length: Overall length is reasonable, but repeated documentation handling, redundant initialization, and verbose modifier checks add noise. Action granularity: Statements generally perform one action per line, though long chained expressions and compound conditions require extra effort. Reading flow: Consistent formatting and sequential visitor processing support navigation, but frequent casts, lengthy conditions, and switches between unrelated class-analysis tasks interrupt the flow.

Run 2

Code Structure: Visitor overrides logically separate AST node handling, but visitClassDef combines documentation collection, name-clash resolution, decorator registration, and static initialization analysis. Nesting: Several deeply nested conditions inside the member loop make paths difficult to follow. Clarity of intent: Descriptive class and API names plus introductory documentation establish the purpose, but short names such as m and def, complex predicates, and an unparenthesized mixed &&/|| condition reduce clarity. Code length: Mostly purposeful, though redundant initialization and verbose boolean assignment add noise; extracting helpers would simplify the longest method. Action granularity: Statements generally perform one action per line, with consistent formatting, although chained calls and casts create dense expressions. Reading flow: The visitor organization and final processing pass are natural, but repeated documentation handling and shifts between unrelated class-analysis tasks interrupt the flow.

Run 3

Code Structure: Visitor overrides provide logical organization, but visitClassDef combines documentation collection, inheritance analysis, name-clash resolution, and static initialization tracking. Nesting: Several conditionals inside the member loop reach substantial depth, making individual paths harder to follow. Clarity of intent: Descriptive class and API names and the class-level documentation explain the overall purpose; terse variables such as m and a mixed &&/|| condition without grouping obscure details. Code length: Reasonable overall, but redundant initialization, repeated casts and modifier checks, and duplicated documentation handling add avoidable verbosity. Action granularity: Most statements perform one action per line, although chained calls and long conditional expressions demand extra parsing. Reading flow: Consistent formatting and conventional visitor ordering help, but the large class visitor shifts between unrelated concerns and would read more naturally with focused helper methods.