As you can see, there is nothing special about this code: just a bunch of transformations and other operations. Nevertheless, the static analyzer didn\u2019t like it. We can see two warnings here:<\/p>\n
The IDE says that the That’s redundant indeed. But why is the expression always true? This was the first time I saw this code, and I spent a lot of time thinking about it. Initially, I was almost sure I\u2019d stumbled upon a bug in the analyzer and I would have to fix it. Let’s see if that’s true.<\/p>\n First, let’s mark all of the lines where the method state changes. There is a change in the variable Lines ‘A’ and ‘B’ (‘B’ is the first branch of the conditional operator) change the variable cur; ‘D’ changes the list; \u0430nd ‘C’ (the second branch of the conditional operator) changes both the list and the variable Line ‘A’ changes Line ‘B’ also works only if Line ‘C’, like the previous ones, works when Finally, line ‘D’ increases the list size: it can turn an empty list into a non-empty one or enlarge a non-empty list. It can’t make a non-empty list empty, though:<\/p>\n What does this give us? Literally nothing. It’s confusing why I have marked the initial state with a double border when entering the method. Well, let’s try again. ‘A’ changes ‘B’ only works when ‘C’ only works when At last, ‘D’ can start at ![\"screen\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/11\/idea-screen.png\")
<\/a><\/p>\nres.isEmpty()<\/code> condition is always true, and, when checking cur<\/code>, it reports a meaningless assignment operation as this variable already has the same value. It’s easy to see that the problem with the assignment is a consequence of the first problem. If res.isEmpty()<\/code> really is always true, then the line is reduced to:<\/p>\nif (cur == -1) cur = -1;<\/pre>\n
res<\/code> is a list populated in the same loop. The IDE doesn’t know how many times the loop iterates and which branches will be visited, as this depends on the input parameters. For example, if an element was added to res<\/code> on the previous iteration, the list won’t be empty.<\/p>\ncur<\/code> or the changing list res<\/code>:<\/p>\nprivate static List process(Map
cur<\/code>. It is important whether or not cur<\/code> equals -1 and whether the list is empty. That is, we have to watch four states:<\/p>\n<\/a><\/p>\ncur<\/code> if it was equal to -1 before. We don’t know if the result will be -1 or not. Therefore, there are two possible options:<\/p>\n<\/a><\/p>\ncur<\/code> equals -1. But, as we’ve already seen, it’s not doing anything. However, let’s mark this edge on the graph to get the whole picture:<\/p>\n<\/a><\/p>\ncur == -1<\/code> and changes it arbitrarily (just as ‘A’ does). Additionally, it can turn a non-empty res<\/code> list into an empty one, or leave it non-empty if there was more than one element in it.<\/p>\n<\/a><\/p>\n<\/a><\/p>\nres.isEmpty()<\/code> is allegedly always true.
\nActually, we started out incorrectly. In this case, it\u2019s not enough to check the state of each variable separately. Correlating states play an important role here. Fortunately, 2+2 = 2*2<\/code>, so we only have four of them:<\/p>\n<\/a><\/p>\ncur<\/code> or keeps it the same at any res, while res<\/code> doesn\u2019t change:<\/p>\n<\/a><\/p>\ncur == -1 && res.isEmpty()<\/code> and doesn’t do anything. So, we add:<\/p>\n<\/a><\/p>\ncur == -1 && !res.isEmpty()<\/code>. Both cur<\/code> and res<\/code> change arbitrarily: after ‘C’ we find ourselves in any state:<\/p>\n<\/a><\/p>\ncur != -1 && res.isEmpty()<\/code> and make the list non-empty, or start with cur != -1 && !res.isEmpty()<\/code> and not go anywhere:<\/p>\n