JSS Science & Technology University: Writing Clean Java Code a Mentor Will Approve

A mentor approves Java code when it can be read once and understood: names say what things are, each method does one job, errors are handled on purpose, and comments explain why rather than what. This article gives you a scoring rubric for those four areas, before-and-after snippets, and a short routine to run before every commit, written for JSS Science & Technology University students who submit Java work for review.

What a Mentor Actually Checks in the First Five Minutes

Reviewers rarely run your program first. They open the file, scroll, and form an opinion from the surface: Can I tell what this class is for? Are there methods that run past one screen? Is there an empty catch block? Are there comments that repeat the code? If the answer to any of these is bad, they stop reading logic and start writing review comments about style, and your real design gets less attention.

That is why clean code is not decoration. It buys you a review focused on whether your solution is correct. The rubric below turns the reviewer’s instincts into criteria you can score yourself before anyone else sees the code.

The Clean-Code Review Rubric for Java: Ten Criteria, Scored 0 to 2

Score each criterion 0 (fails), 1 (partly meets) or 2 (meets). The maximum is 20. Treat anything under 15 as “not ready to submit.”

Naming: Before and After Java Snippets

The snippets below are illustrative teaching examples. They are not taken from any course and have not been compiled or run here, so compile and test your own versions.

Before:

public double calc(double a, double b, int c) {
    return a * b * c / 100;
}

After:

private static final double PERCENT_DIVISOR = 100.0;

public double calculateSimpleInterest(double principal,
                                      double annualRatePercent,
                                      int years) {
    return principal * annualRatePercent * years / PERCENT_DIVISOR;
}

What changed: the method name states the outcome, the parameters carry units (a percent, not a fraction), and the literal has a name. A reader no longer needs the formula in their head to know the code is right.

Quick naming rules worth memorising

• Booleans read as questions: isEligible, hasStock, not flag or status.
• Collections are plural: students, not studentList2.
• Avoid encodings such as strName or iCount; Java’s types already carry that information.
• If you cannot name a method without using “and”, it probably does two jobs.

Method Length: Splitting One Long Method Into Readable Steps

A long method is usually several short methods stuck together. Look for blank lines and comments that act as section dividers; each one marks a candidate method.

Before (illustrative):

public void process(Order o) {
    if (o == null || o.getItems().isEmpty()) {
        System.out.println("bad order");
        return;
    }
    double total = 0;
    for (Item i : o.getItems()) {
        total += i.getPrice() * i.getQty();
    }
    if (total > 5000) {
        total = total - total * 0.1;
    }
    System.out.println("Total: " + total);
}

After (illustrative):

private static final double BULK_THRESHOLD = 5000;
private static final double BULK_DISCOUNT_RATE = 0.10;

public void printOrderSummary(Order order) {
    validate(order);
    double payable = applyBulkDiscount(sumItems(order));
    System.out.println("Total: " + payable);
}

private void validate(Order order) {
    if (order == null || order.getItems().isEmpty()) {
        throw new IllegalArgumentException("Order must contain at least one item");
    }
}

private double sumItems(Order order) {
    double total = 0;
    for (Item item : order.getItems()) {
        total += item.getPrice() * item.getQty();
    }
    return total;
}

private double applyBulkDiscount(double total) {
    return total > BULK_THRESHOLD ? total * (1 - BULK_DISCOUNT_RATE) : total;
}

The top method now reads like a sentence. Each helper can be unit tested alone, and a change to the discount rule touches one place. Note that the “after” version also moved printing out of the validation path and replaced a console message with an exception, which leads to the next area.

Exceptions: Replacing Swallowed Errors With Handled Ones

Before (illustrative):

public String readConfig(String path) {
    try {
        BufferedReader r = new BufferedReader(new FileReader(path));
        return r.readLine();
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

Three problems: the reader is never closed, the catch is too broad, and the caller receives null with no idea what went wrong.

After (illustrative):

public String readFirstConfigLine(Path path) {
    try (BufferedReader reader = Files.newBufferedReader(path)) {
        return reader.readLine();
    } catch (IOException e) {
        throw new ConfigLoadException("Could not read config file: " + path, e);
    }
}

Here ConfigLoadException is a small custom exception you would define yourself. The original IOException is passed as the cause, so the stack trace still shows the real failure.

Exception checklist for every try block

• Can I catch a narrower type than Exception?
• If I catch it, what do I do about it: recover, translate, or log and rethrow?
• Does the message include the value that caused the failure (file path, id, input)?
• Is every resource closed by try-with-resources?
• Am I returning null to hide a failure? Prefer an exception, an Optional, or an empty collection.

Comments: Keeping Only the Ones That Explain Why

Before (illustrative):

// loop through students
for (Student s : students) {
    // check if marks are greater than 40
    if (s.getMarks() > 40) {
        // add to list
        passed.add(s);
    }
}

After (illustrative):

private static final int PASS_MARK = 40;

for (Student student : students) {
    // Pass mark is exclusive here: exactly 40 is treated as a fail
    // to match the department's sample answer sheet.
    if (student.getMarks() > PASS_MARK) {
        passed.add(student);
    }
}

The first set of comments repeats the code. The second keeps one comment that records a decision a reader could not infer. (The rule in this example is invented for illustration; in your own work, write down the real rule and where it came from.) Public methods deserve Javadoc stating what the method does, what its parameters mean and which exceptions it throws.

Scoring a Submission With the Rubric: A Worked Illustration

Imagine a student submits a small library-fine calculator. This is a made-up case to show the scoring, not a real submission.

Total: 7 out of 20. The fixes, in priority order: replace the empty catch with a specific handler, split main into read, compute and print methods, name the fine constant, delete dead code, then add three unit tests for the fine calculation (on time, one day late, many days late). Rescoring after those changes would plausibly land above 15, which is the point of the exercise: the rubric tells you what to fix first.

The Pre-Commit Self-Review Routine

Run this before every commit, not just before the final submission. It takes ten to fifteen minutes once you are used to it.

1. Read your own diff. Run git diff --staged and read it as if a stranger wrote it. Remove stray debug prints and unrelated changes.
2. Compile and run all tests. Use your build tool (Maven or Gradle) or the IDE test runner. A commit that does not build wastes the reviewer’s time.
3. Naming pass. Search the diff for single-letter variables, temp, data, flag, and methods named process or handle. Rename.
4. Length pass. Any method that does not fit on one screen gets split. Any method with a “section comment” gets split.
5. Exception pass. Search for catch. Every one must do something intentional. Search for return null and justify each.
6. Comment pass. Delete comments that restate code and commented-out blocks. Add one “why” comment where a decision is not obvious.
7. Format. Run your IDE’s reformat command so indentation and imports are consistent; remove unused imports.
8. Write the commit message. One line in the imperative mood, such as “Add late-fee calculation with unit tests”, plus a short body if the reason is not obvious.
9. Score yourself. Use the rubric. If you are below 15, fix before pushing.

A 14-Day Plan to Build the Habit

If you are doing a two-week project or internship, spread the practice across the 14 days rather than cleaning everything on the last night. The free two-week online internship at CareerSwami (free offer letter, free completion certificate after successful completion, 26 tracks) fits this pacing well if you choose a Java-related track; the same plan works for any 14-day Java task.

JSS STU Students: Why Code Quality Matters Around Placement Season

JSS Science & Technology University’s Placement Policy (the version we reviewed is dated 2024, so check for a newer one) describes the Training and Placement Department as a facilitator and counsellor. It does not promise a job or 100% placement. In practice, that means your own evidence of skill carries the weight, and a small, clean Java repository you can walk an interviewer through is exactly that evidence.

The same policy has process rules that affect how you schedule your coding practice. It requires online registration before a company’s deadline, accepts no late entries, and makes attendance at the Pre-Placement Talk mandatory. It also lists grounds for debarment, including attendance below 80% in any academic subject and less than 100% attendance in the placement-training modules. A pre-commit routine helps here because it is short enough to fit around a full timetable; you do not need long late-night cleanup sessions that cost you class attendance.

The policy further explains how internship-only offers interact with later full-time offers, with a CTC margin that depends on the internship company’s package. If you receive such an offer, read that clause in the current document and ask the T&P office to explain it in writing before you accept anything.

Whether a Java internship or project completed outside the university counts toward any university requirement is a separate question, and this article does not assume it does. Treat the CareerSwami internship as extra practice and portfolio material unless your department tells you otherwise.

Verification steps for JSS STU students

1. Download the current Placement Policy from the university’s official site and compare its date and clauses with the 2024 version linked above.
2. Ask the T&P office which coding-round topics (Java, data structures, SQL) recruiters in your branch typically test, and request any preparation schedule in writing.
3. Check the placement-training module attendance rules for your batch, and put the dates in your calendar next to your commit-practice slots.
4. Email your department coordinator to ask whether external or online internships are recorded in any official way, and what proof they would need.
5. Ask your Java faculty or lab mentor whether they use a code-review checklist or style guide, and adopt its rules ahead of this rubric where they differ.

Using a Mentor’s Review Comments to Raise Your Score

When a mentor returns comments, log them. Keep a simple table in your repository’s notes file: the comment, which rubric criterion it falls under, and the fix. After a few reviews, patterns appear. Most students find one or two criteria produce most of their comments, often exceptions or method length. Make those the first two items in your self-review until the comments stop.

• Reply to each comment with the commit that addresses it.
• If you disagree, give a reason in a sentence; reviewers respect reasoned pushback.
• Do not fix only the line they flagged; search for the same problem elsewhere in the project.

Frequently Asked Questions

How long should a Java method be before a mentor complains?

There is no universal limit, but around 20 lines is a useful warning level. The better test is whether the method does one job at one level of detail. A 25-line method that only loops and sums is fine; a 12-line method that validates, calculates and prints is not.

Is it ever acceptable to catch Exception in Java?

Yes, at the outermost boundary of a program, such as a main method or a request handler, where you log the failure and exit cleanly or return an error response. Inside business logic, catch the narrowest type you can actually handle.

Should I comment every method?

Not every method. Write Javadoc for public classes and methods that others will call, and add inline comments only to record reasons or non-obvious decisions. Clear names remove the need for most explanatory comments.

Do I need unit tests to score well on this rubric?

The rubric gives the last criterion up to 2 points for formatting and tests together, so tests are not the whole score. They are still the quickest way to prove that your refactoring did not change behaviour, so add tests for core logic first.

What do I do if my IDE formatter and my college lab use different styles?

Follow the style your faculty or lab mentor specifies, and ask for it in writing if it is unclear. If none is given, use one consistent convention such as the commonly used Google or Oracle Java style and apply it through the IDE formatter across the whole project.

How often should I commit while practising clean code?

Commit after each small, working change, such as one extracted method or one fixed exception path. Small commits make the pre-commit routine fast and let a reviewer see your refactoring steps clearly.

Can I show the before-and-after refactoring in an interview?

Yes, and it is a strong move. Keep an early commit and the cleaned version, and be ready to explain which rubric criterion each change addressed. Do not claim results you cannot demonstrate, and make sure you can run the code on the spot.

Related Java & Enterprise Software guides

• Al-Karim University Students: Starting a Java Internship With Only Basic English Confidence
• Uttaranchal University Students: Building a GitHub Profile From Java Internship Work
• Om Sterling Global University: Learning REST Versus SOAP in Enterprise Java Internships
• All Java & Enterprise Software internship guides