Correctly formulate conditions for constants?

Question

I have a constant in my project, that represents some timespan. When it is below 0, I want to disable the timespan related checks.

Normally one would check

if(CONSTANT > 0) foo();
else bar();

but this causes the warning "Condition is always 'false'" or "Condition is always 'true'" depending on the value of the constant.

Is there a way to circumvent this warning, to prevent another dev to just that lines?

EDIT: I was a bit too generic with my question. Sorry about that.

I'm having a Timer, that after some time TIME_FOR_AUTH (the constant) has passed, clears my model. This is a security measure, that makes problems while testing. Therefore I added a check, if(TIME_FOR_AUTH > 0) ... to my code.

Now I get the described warning. Since IntelliJ always asks me to delete this construct (and I'm not alone in this project), I wanted to know if there is a common practice doing that in Java / some possibility to suppress the warning.

constants do not change (that't why you get the warning), otherwise you're misusing the concept. — lealceldeiro, Jun 15 '19 at 13:28
@lealceldeiro I'm aware, that constants don't change in the running code. But I'm using the one described to enable (or diable) a Timer in my program and also set the time with it. I'm not sure what other concept would be usable for that. — dCSeven, Jun 15 '19 at 13:41
Your question is unclear, as illustrated by the "debate" between the two answers about what you are asking! Please read those answers, and then *clarify* your question so that people can understand what you are actually asking. Please clarify by editing the question ... — Stephen C, Jun 15 '19 at 13:42

Dmitriy Popov · Answer 1 · 2019-06-15T13:33:59.907

4

At first, this is just a warning.

At second, you can suppress the warning using @SuppressWarnings annotation. For "is always true/false" warning, it would be @SuppressWarnings("ConstantConditions")

Code example:

package stackoverflow;

public class SuppressWarningsExample {

    @SuppressWarnings("ConstantConditions")
    public static void main(String[] args) {
        final int value = 100;

        if (value > 0)
            System.out.println("Yes");
        else
            System.out.println("No");
    }
}

For IntelliJ IDEA, you can also suppress warning per-expression with an inline // noinspection <InspectionName> comment:

// noinspection ConstantConditions
if (value > 0)
    System.out.println("Yes");
else
    System.out.println("No");

edited Jun 15 '19 at 13:33

answered Jun 15 '19 at 13:29

Dmitriy Popov

2,150
3
25
34

2

I actually thing that the question is about when you _consciously_ know that the expression is constant (you usually do this for temporary excluding some piece of code. For instance, I sometimes do `if (true) { doSomething(); return;}`, to execute only some part of the method in some complex debug without drastic change of code), and getting rid of the annoying warning. In the text of the issue, the same target is pretty clearly defined with "to prevent another dev to just that lines", eg to temporarily execute only one part of the code without removing the rest of the method code. – Dmitriy Popov Jun 15 '19 at 13:36
1

Surely it is just a warning, but one, that always suggests me to delete that piece of code ;) and I wasn't aware that these can be suppressed that easily. Thanks – dCSeven Jun 15 '19 at 14:00
Yeah, I understand the problem with delete suggestion. Note that you can also add `@SuppressWarning` in IDEA pretty much automated with Alt + Enter on the problematic expression → press Right on "Unwrap 'if' statement" option → select some of "Suppress for ..." actions. – Dmitriy Popov Jun 15 '19 at 14:04

GhostCat · Answer 2 · 2019-06-15T15:22:41.390

Here:

if(CONSTANT > 0) foo();

You say it yourself. It is a constant. Thus, right from the start, it is either bigger or smaller than 0. Thus the compiler gleefully turns the above into:

if(...x... > 0) foo();

where x would be the actual value that you assigned to CONSTANT. So right there, at compile time, this turns into

if (true)

or maybe if (false).

Long story short: rethink what you are doing. Probably you shouldn't comparing your CONSTANT, but something like:

LocalDateTime endTime = LocalDateTime.now().plusHours(1);

and then, later:

if (LocalDateTime.now().isAfter(endTime)) {

or something like that.

In other words: comparing a constant value to identify a certain condition simply doesn't much sense. Instead you can use the constant to compute some "end time", and then, over time check the current time against that "end time". Especially when using a class like LocalDateTime it is extremely easy to compute a later timestamp, as shown above.

Edit, given the edit to the question: I still suggest to NOT have such a construct in production code. Instead, I would look into means so that the test setup can configure the production in a way that allows it to effectively disable such a timeout mechanism. For example by injecting a timeout that is guaranteed to not be hit during reasonable test execution time!

Thats a great idea, thanks. Sadly it doesn't fit for my concrete problem, but I'll remember it for later. — dCSeven, Jun 15 '19 at 13:54

Correctly formulate conditions for constants?

2 Answers2