java unused assignment

PhpStorm 2023.2 Help

Code inspection: unused assignment.

Reports a variable whose value is never used after assignment.

Suggests removing the unused variable to shorten the code and to avoid redundant allocations.

The following cases are reported:

A variable is never read after assignment.

The value of a variable is always overwritten with another assignment before the variable is read next time.

The initializer of a variable is redundant (for one of the above-mentioned reasons).

Suppress an inspection in the editor

Click the arrow next to the inspection you want to suppress and select the necessary suppress action.

• United States
• United Kingdom

By Dustin Marx , JavaWorld |

A software developer's public collection of tips and tricks, real-world solutions, and industry commentary related to Java programming.

NetBeans 7.1's Unused Assignment and Dead Branch Hints

One of the new code hints provided by NetBeans 7.1 is the Unused Assignment hint. A simple code sample that will cause this hint to be displayed in NetBeans 7.1 is shown next.

Demonstrating Unused Assignment

In the code above, the local variable "i" is initialized to 2, but is never used and then is initialized again, making the first initialization unnecessary. The next image is a screen snapshot that shows NetBeans 7.1 displaying a warning code hint for the unused assignment.

As the above image indicates, NetBeans 7.1 warns of "The assigned value is never used."

The New And Noteworthy in NetBeans IDE 7.1 page mentions this hint among others and states:

Unused Assignment A new pair of hints, Unused Assignment and Dead Branch, was introduced. The Unused Assignment finds values that are computed and assigned to a variable, but never used by reading the variable. The Dead Branch hint searches for branches of code that can never be executed.

Oh Dead Branch Hint, Where Art Thou?

The Unused Assignment Hint seems to work as suggested based on the example shown above. However, I have not been able to generate code that demonstrates the "Dead Branch" hint. I wonder if the Dead Branch hint is not yet supported and text related to it is not supposed to be under the "Unused Assignment" heading.

The following code contains a listing with several methods that I would expect might potentially lead to a warning about a dead code branch. None of these cause this code hint to appear in any form (warning or error) in my installation of NetBeans 7.1.

Methods With Compilable Dead Code Branches

Although none of the methods in the directly previous code listing lead to the Dead Branch code hint, NetBeans 7.1 does include configuration options for the Dead Branch hint. This is shown in the next screen snapshot (selecting Tools->Options followed by the "Editor" tab and then selecting "Hints").

The NetBeans 7.1 News and Noteworthy page shows examples of other new hints , but does not show an example of the Dead Branch hint. Also, the text talking about Dead Branch is mixed with the section on Unused Assignment and under a heading that only talks about Unused Assignment. As my previous code listing demonstrates, I attempted to come up with a code sample to demonstrate the Dead Branch hint, but have not been able to do so. The purpose of this hint ("search[ing] for branches of code that can never be executed") sounds like a nice complement to compiler errors such as " unreachable statement " and " exception already caught " and other NetBeans "green" warnings such as "variable such-and-such is not used."

I have blogged about NetBeans hints before and the addition of new hints in NetBeans 7.1 is welcome. If anyone knows of a code sample that will demonstrate the Dead Branch hint in NetBeans 7.1, please share!

Original posting available at http://marxsoftware.blogspot.com/ (Inspired by Actual Events)

This story, "NetBeans 7.1's Unused Assignment and Dead Branch Hints" was originally published by JavaWorld .

Next read this:

• The best open source software of 2023
• Do programming certifications still matter?
• Cloud computing is no longer a slam dunk
• What is generative AI? Artificial intelligence that creates
• Coding with AI: Tips and best practices from developers
• Why Wasm is the future of cloud computing

Dustin Marx is a principal software engineer and architect at Raytheon Company. His previous published work for JavaWorld includes Java and Flex articles and " More JSP best practices " (July 2003) and " JSP Best Practices" (November 2001).

Copyright © 2012 IDG Communications, Inc.

• | Log In [x]
• | Forgot Password Login: [x]

This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues .

• Format For Printing
•  -  XML
•  -  Clone This Bug
•  -  Top of page

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[java] UnusedAssignment should be able to ignore unused parameters of overriding methods #4281

Frettman commented Jan 5, 2023

oowekyala commented Jan 10, 2023

Sorry, something went wrong.

Frettman commented Jan 10, 2023

jsotuyod commented Jan 10, 2023 • edited

• 👍 1 reaction

No branches or pull requests

IDE extension that lets you fix coding issues before they exist!

Setup is effortless and analysis is automatic for most languages

Self-Hosted

Fast, accurate analysis; enterprise scalability

Why is this an issue?

Dead stores refer to assignments made to local variables that are subsequently never used or immediately overwritten. Such assignments are unnecessary and don’t contribute to the functionality or clarity of the code. They may even negatively impact performance. Removing them enhances code cleanliness and readability. Even if the unnecessary operations do not do any harm in terms of the program’s correctness, they are - at best - a waste of computing resources.

The rule ignores

• Initializations to -1 , 0 , 1 , undefined , [] , {} , true , false and "" .
• Variables that start with an underscore (e.g. '`_unused’) are ignored.
• Assignment of null is ignored because it is sometimes used to help garbage collection
• Increment and decrement expressions are ignored because they are often used idiomatically instead of x+1
• This rule also ignores variables declared with object destructuring using rest syntax (used to exclude some properties from object)

How to fix it

Remove the unnecesarry assignment, then test the code to make sure that the right-hand side of a given assignment had no side effects (e.g. a method that writes certain data to a file and returns the number of written bytes).

Code examples

Noncompliant code example, compliant solution.

• CWE - 563 - Assignment to Variable without Use ('Unused Variable')

Related rules

• S1763 - All code should be reachable
• S2589 - Boolean expressions should not be gratuitous
• S3516 - Function returns should not be invariant
• S3626 - Jump statements should not be redundant

Getting Rid Of Unused Variables (Finally) - Inside Java Newscast #46

JEP 443 proposes to add unnamed variables and patterns to Java. With them, unused variables and patterns can be replaced by a single underscore, which helps writing readable and maintainable code.

Always embed videos

( and give me a cookie to remember - privacy policy )

Watch on YouTube

Share this post with your community:

I'm active on various platforms. Watch this space or follow me there to get notified when I publish new content:

Welcome everyone, to the Inside Java Newscast where we cover recent developments in the OpenJDK community. I'm Nicolai Parlog, Java developer advocate at Oracle, and today we're gonna get rid of all those variables you had to declare even though you didn't want to use them. No need for this first parameter of that lambda? Now it's gone! Don't care about the exception? Gone! No use for all those destructured record components? Guess what? Gone!

Because today we're gonna talk about JEP 443: unnamed patterns and variables. They're mainly about convenience and clarity, and we'll go over that first, but you'll also see why they will play a critical role in writing maintainable pattern matches.

Ready? Then let's dive right in!

▚ The Situation

Unused variables are pretty annoying: IDEs turn them grey or give you squiggly lines, code linters give you stink eye, and your colleagues are tattling about yours behind your back. And they all have good reason! Until they don't. Because sometimes it just can't be helped.

Maybe you're implementing a BinaryOperator but only need the second argument. Maybe your error handling doesn't depend on the specific exception you're catching. Maybe the resource in your try-with-resources block only needs to be opened and closed but you don't want to interact with it. Then there's the rare for-each loop where you don't actually need the loop variable. And in even rarer cases you may want to capture a method's return value even though you don't want to use it.

These situations are pretty uncommon (although the unused lambda parameter pops up a bit more often in my code) but if you've already experimented with record patterns, you know that not needing all the destructured components is actually pretty common. And deconstruction itself will become more common. At the moment, it only works with records in pattern matching but both of those limitations may be relaxed in the future: Classes in general may get explicit deconstructors and deconstruction on assignment and in for each loops is also on the horizon.

So the future brings more deconstruction, which will bring more unused variables.

▚ The Workarounds

But what can you do if you want or - more likely - need to declare a variable that you're not going to use? Some devs give the variable a regular name and simply ignore it. Others punish it by cutting its name short to a single letter - no self-documenting name for you! You could name it unused . But none of these are ideal.

Here's what I do: Java 8 deprecated the use of the single underscore for variable names and Java 9 forbade it - it's been a compile error ever since.

So I use the double underscore for such variables.

Until I need two of them in the same scope - then I have to up it to three. But that doesn't keep the IDEs and linters from complaining either.

So, all in all, not a great situation. It hasn't been a big problem in the past but with deconstruction patterns becoming more common, it will become very annoying very quickly. So somebody needs to do something about it!

▚ The Solution

Thankfully the good people working on Project Amber are on it! I just said that Java 8 deprecated and Java 9 forbade the use of the single underscore, right? That happened for exactly this scenario! (Which is where I got the idea to use two underscores from. Yeah, I'm not very creative.)

So Project Amber brought forth JDK Enhancement Proposal 443: unnamed patterns and variables. In a nutshell, you can use the single underscore in place of a variable name or a pattern but you can never refer to it - you can't "declare" String _ and then call _ . length ( ) . And because _ does not actually refer to a variable, you can use it several times in the same scope. If you don't need that lambda parameter nor that exception nor those two record components, you can use _ for all of them!

Marking unused variables this way has a number of benefits: The most obvious one is that we no longer have to come up with names for them. (I can already feel the stress falling away.) Then it removes visual clutter and clearly communicates to your colleagues that the variable is unused. The same is true for compiler and linters, so we can expect fewer warnings from them. And then there's the pattern matching bonus that I mentioned in the intro but before we get to that I want to go over a few details of the proposal.

▚ The Details

Technically, the proposal consists of three parts:

• unnamed variables
• unnamed variables in patterns
• unnamed patterns

Let's take it one by one. Unnamed variables replace the variable name in

• a local variable declaration
• a resource specification of a try-with-resources statement
• the header of a basic or enhanced for loop
• an exception parameter of a catch block
• a formal parameter of a lambda expression

If you want, you can use unnamed variables with var and just like there, there must always be an initializer, for example an expression on the right-hand side of a local variable declaration. Declaring an unnamed variable does not place a name in scope, which are fancy words for it can't be written or read after it has been initialized. And since nothing is placed in scope, there's no shadowing and you can declare multiple such variables.

Unnamed pattern variables replace the variable name in, wait for it, patterns. Namely, in type and record patterns, because that's all we have at the moment. They do require explicit types, though.

If you want to get rid of the type information, too, basically writing var _ , you have an unnamed pattern and don't the need the var after all - just replace the full type-and-variable-name with _ . Unnamed patterns bind nothing but match everything, which is why they don't make sense at the top level and so are forbidden there: They can only be used in nested positions in place of a type or record pattern.

I mentioned that this will play a critical role in writing maintainable pattern matches. In particular, I was referring to unnamed patterns in switches because they make it more convenient to avoid default branches.

Now, why would you want to do that? In order to implement behavior that differs by type, you want to switch over a sealed supertype and then exhaustively and explicitly list all possible subtypes.

That way, when a new subtype gets added, you can follow the compile errors to all the switches that need to be updated.

Now, if you'd have used a default branch, the switch would still be exhaustive and you wouldn't get a compile error - the code would silently run into that branch whether that's correct or not.

Ok, so we need to avoid default branches by explicitly listing all possible subtypes. But sometimes you just have "defaulty" behavior for a few of those branches and so you want to combine them. But while multiple case labels are legal since Java 14, multiple named patterns are not. Because case Triangle t , Rectangle r doesn't make any sense - you could use neither t nor r because the compiler doesn't know which one matched.

And this is where unnamed patterns come in! With them, you can use multiple unnamed patterns in a single case label: case Triangle _ , Rectangle _ . You still don't know which pattern matched, but since you can't refer to any variable anyway, that doesn't matter.

So here's my recommendation for switches over a sealed supertype:

• handle all subtypes explicitly
• do not use a default branch
• if you have default behavior, use multiple unnamed patterns in a single case to match the relevant subtypes

This way, you have just a bit more code than with a default branch but in return the compiler will point you to this switch if you add a new subtype. To me, beyond the convenience and clarity JEP 443 will doubtlessly bring to our code, this is the biggest benefit because it really helps write more maintainable code. When we'll start doing that is not settled, though - the JEP is not yet targeted to a release.

(By the way, have you noticed that we've moved past the must-have list of pattern matching features and got to the nice-to-haves? Yeah, Java has pattern matching now. Incredible.)

And that's it for today on the Inside Java Newscast. If you like these videos, do me a favor and let YouTube know. In two weeks, Ana will tell you all about the biggest improvement Java's strings have ever seen - yes, bigger even than text blocks. Subscribe and ring the bell, so you won't miss it. I'll see you again in four weeks. So long...