Incorrect analyzer feedback: finalSalary should not be forced to use a ternary when Math.min is clearer

[nilvon9wo]

The Java analyzer is giving this automated feedback:

“As the goal of this exercise is to learn about ternary operators consider using them in finalSalary to solve this exercise.”

However, this feedback appears to be incorrect.
My implementation does use ternary operators where appropriate (e.g., in salaryMultiplier and bonusMultiplier), and the logic inside finalSalary does not naturally lend itself to a ternary expression. Instead, the method concludes by applying a salary cap using:

return Math.min(salary, MAX_SALARY);

This is the most idiomatic and intention-revealing way in Java to express “cap a value at a maximum.”
Forcing a ternary here would reduce clarity, for example:

return salary > MAX_SALARY ? MAX_SALARY : salary;

Both statements are functionally equivalent, but the Math.min version:

• more clearly communicates the intent,
• avoids nesting logic inside a ternary,
• reflects common Java practice,
• is simpler to read and maintain,
• aligns with standard clean-code guidelines.

The goal of the exercise is to learn ternary operators, not to artificially apply them in places where they decrease readability or duplicate existing standard library functionality.

Since the solution already uses ternaries appropriately and idiomatically in earlier methods, the analyzer's suggestion is misleading and encourages worse code, not better code. The feedback should either:

1. detect that ternaries are used elsewhere and suppress this suggestion, or
2. avoid prescribing the use of a ternary in situations where another construct is objectively clearer.

In short, the feedback should guide learners toward idiomatic, expressive Java—not toward unnecessary or forced use of syntax.

If needed, I can provide a minimal code example illustrating the issue.

[kahgoh]

I think the feedback is fine.

However, this feedback appears to be incorrect.

What does your solution look like? The feedback mentions finalSalary in the comment:

“As the goal of this exercise is to learn about ternary operators consider using them in finalSalary to solve this exercise.”

If you've just used Math.min, that is not the ternary operator.

I agree that it is kinda artificial and duplicates a bit of library functionality, but I think that is fine for a bit of practice.

[nilvon9wo]

@kahgoh ,
I understand why I'm getting that feedback, but when I'm already demonstrating I can use the ternary operator, I don't think I should be receiving feedback which might discourge me from solving the problem in a better way. :-)

This is my solution:

public class SalaryCalculator {
	private static final double BASE_SALARY = 1000.0;
	private static final double MAX_SALARY = 2000.0;

	private static final int BONUS_THRESHOLD = 20;
	private static final int BONUS_LOW = 10;
	private static final int BONUS_HIGH = 13;

	private static final int SKIP_DAY_THRESHOLD = 5;
	private static final double SALARY_FULL = 1.0;
	private static final double SALARY_REDUCED = 0.85;

	public double salaryMultiplier(int daysSkipped) {
		return daysSkipped >= SKIP_DAY_THRESHOLD
				       ? SALARY_REDUCED
				       : SALARY_FULL;
	}

	public int bonusMultiplier(int productsSold) {
		return productsSold >= BONUS_THRESHOLD
				       ? BONUS_HIGH
				       : BONUS_LOW;
	}

	public int bonusForProductsSold(int productsSold) {
		return productsSold * bonusMultiplier(productsSold);
	}

	public double finalSalary(int daysSkipped, int productsSold) {
		double salary = BASE_SALARY * salaryMultiplier(daysSkipped)
				                + bonusForProductsSold(productsSold);

		return Math.min(salary, MAX_SALARY);
	}
}