Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

This is an instalment of my Code Odium series of articles talking about bad programming practices with focus on Java. In this article I will talk about the practice of declaring variables in a method parameter list only to use them as local variables.
code_issues.jpg


This is the kind of code that I've come across a number of times during some of my code reviews...
 Java
public void myMethod(MyObject myObj) {
/* code that doesn't reference myObj */
myObj = new MyObject();
/* code that manipulates myObj variable */
}


Then of course there is the method call to myMethod() that looks like this...
 Java
myMethod(null);


So what's wrong with this?

1. No parameter scoped variable should ever be reassigned inside a method and in fact your parameters should be declared as final to prevent this.

2. Declaration of a variable should be done within its correct scope - if you intend to use a variable as a local variable, declare it so. In this case declaring the variable as a parameter implies that it's an input value that the method requires to run.



The problems identified above are quite severe, but I think the next problem with this code is the most important in this case -

3. Readability and maintainability. If someone comes along who has never seen this code before, they will naturally assume that the method requires some sort of input. This of course would be an incorrect assumption in this particular case, which in terms increases the complexity of what the developer has to keep in mind while working with this code. If this issue isn't fixed, the next developer that comes along faces the same challenge. This decreases productivity and makes it more difficult to maintain a good code base.

4. Of course don't forget the fact that you still need to pass some value when calling the method - a null in my example! This does mean the value goes on the stack and there is a little bit of memory and CPU cycles used for that, I wouldn't consider this as a real performance problem however, but it is wasteful.

So a few things to learn from the above, and just remember - declare variables only when you need to use them and not beyond that.

All code examples shown above have been obfuscated from their original versions but still show similarities in terms of style.

-i

Please leave your comments or feedback below!
comments powered by Disqus
Other posts you may like...
Hi! You can search my blog here ⤵
Or browse the recent top tags...

Recent Blog Posts

Mini review of the Sonoff B1 WiFi light bulb

Coherence cache performance optimistic vs replicated schemes

Coherence and weblogic.xml in different types of J2EE web app deployments

Atari Lynx repair - Part 5 - McWill LED screen mod installation

Atari Lynx repair - Part 4 - screen cover replacement

Atari Lynx repair - Part 3 - broken speaker replacement

Atari Lynx repair - Part 2 - re-capping the motherboard

Atari Lynx repair - Part 1 - introduction and case disassembly

jPhotoFrame updated to version 0.3.1 with an image rotation correction utility

iOS 11 pre-GM mini review before it gets revealed next week

Recent Galleries

Atari Lynx repair - Part 5 - McWill LED screen mod installation

Atari Lynx repair - Part 4 - screen cover replacement

Atari Lynx repair - Part 2 - re-capping the motherboard

Atari Lynx repair - Part 3 - broken speaker replacement

Atari Lynx repair - Part 1 - introduction and case disassembly

Building a custom Atari Lynx game box storage shelf unit in a day

Protecting old Atari Lynx game boxes with snug fit plastic sleeves

Monument Valley 2 is released and does not disappoint

Space Food - Chocolate Ice Cream with Chocolate Chips

Legeod Star Wars AT-DP kit

Blogs and Friends

Matt Moores Blog
Georgi's FlatPress Guide
Perplexing Permutations
The Security Sleuth
Ilia Rogatchevski
Travelling Fairy

Blog Activity

Blog Activity