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

WebLogic Maven Plugin - How to fix the MojoExecutionException: The artifact location was not specified

jPhotoFrame version 0.4 released with a whole new layout engine

Upcycling a couple of old broken lamps to create something amazing

A custom exception mapper and writer for a RESTful JAX-RS Jersey service

How to fix Plex error - Sorry there was a problem playing this item

Jersey JAX-RS filters and interceptors execution order for a POST request

Fix your Mac - users not showing on the macOS login screen when FileVault is enabled

BMB-012 Nanoblock T-Rex Skeleton Model assembly

Writing a custom MessageBodyReader to process POST body data with Jersey

How to make Skype for Business responsive again on macOS

Recent Galleries

BMB-012 Nanoblock T-Rex Skeleton Model assembly

Tiny Arcade revision 6 kit assembly and decal application

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

Blogs and Friends

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

Blog Activity

Blog Activity