Data Rattle 18
Take a look at this code:
public static int findPositionInInterval(int [] content, int start, int end) {
for(int n = 0; n < content.length; n++) {
int current = transform(content[n]);
if (start <= current && current <= end) {
return n;
}
}
return -1;
}
How does it look? Great? Poor? Is it code with a glaring problem?
Hold that thought for a second and then take a look at this code:
public static int findPositionInInterval(final int [] content, final int start, final int end) {
for(int n = 0; n < content.length; n++) {
final int current = transform(content[n]);
if (start <= current && current <= end) {
return n;
}
}
return -1;
}
I like it better.
The fact of the matter is: mutable state hurts. Unless you’ve done some functional programming you might not realize that it hurts, but it does. It may feel okay to walk barefoot, but if some gives you a comfy pair of shoes you quickly learn that, well, your feet were irritated by pebbles and twigs and there was a better way of walking around, you just didn’t know about it. Fixing state and making it immutable is just like that. When you become used to that style, you notice that it’s easier to reason about your code.
In my mind’s eye, the first snippet is a like a box containing loose parts. If you shake it, it rattles. Parts that don’t need to move are fixed in place by final. In code as brief as this, it doesn’t smell mightily, but it smells nonetheless.
So mutable data is a smell and we can fix it. However, there’s a problem. I’d argue that the second snippet is just a little noisier than the first one. Java forces us to do something special to make data immutable. C# and C++ are the same way: mutable is the default and immutability requires special keywords. There are some languages which make immutability the default, or least make don’t make you pay the price of an extra token to make something immutable. Haskell, OCaml, Scala, and F# all fit into this category. In the older languages, however, we’ll continue to have a lot of rattling data.
Listen for it.
That wasn’t exactly the change that I was expecting. I was looking more for a null check of the array, and/or checking that start <= end.
I agree that making the parameters final helps and at the very least is a signal to readers that the params are immutable, but wrt to the array, only the reference is protected – you can still muck with its contents.
Java needs a ‘const’ keyword, which you seem to imply that final is giving you, and it’s certainly not.
Noisy indeed. BTW: The guy who invented null should be tracked down and shot. ;)
> So mutable data is a smell and we can fix it Well, es Burt mentioned, that statement doesn’t hold for the array. Correct me if I am wrong but the final keyword denotes that things are not changed inside the method but they can be changed outside by a different thread that changes the array. You might want to have a look at Erik Meijer’s talk on side effect free code (I would place the link here if I could). In his terms, you want to implement the method as “pure function” to avoid side effects but I think that is not feasible in Java apart from trivial cases. Haskell, OCaml, Scala, and F# let you choose to implement pure or not. BTW.: You cannot get rid of mutability all together. It is an inevitable part of life. I agree that it can do allot of harm if used wrongly and I really like the rattle analogy in that context!
(This blog’s spam filter/moderation queue appears to have eaten my message. Let’s try if having no clickable links gets through…)
I also prefer making things mutable. With classes I try to make all fields final and use constructor injection. But with local variables the “final” keyword is too much clutter for my eyes.
Recently I customized IntelliJ IDEA’s syntax highlighter colors so that mutable local variables are highlighted with a different color (purple), so that I would know when to be alert for mutable state. I also chose to highlight interfaces (green) and abstract classes (blue), so that I would know when to be alert for method implementations.
Here is an example of how it looks:
*ttp://img376.imageshack.us/img376/1856/mutableimmutablene2.png
In the first method I see right away from the purple color, that the local “db” variable is modified, so I can be more alert when reading that part of the code.
In the second method the algorithm is quite complicated, but because none of the local variables is highlighted, I can be sure that they are not being modified unexpectedly.
Esko, that mutable-sensitive colour-coding is a fantastic idea.
Sure mutable data hurts. I have been learning scala recently and even prior to that believed mutable data was difficult to reason with. However the example you use is iffy at best. What can you reason about mutable stack elements or local variables? Exactly the same as immutable data in your example. I would not spend the time making primitives on the stack and locals immutable, it is not worth the effort.
In your example I would rather have seen better functional decomposition, a function value (as method argument argument) that captures the transform invocation and a predicate (as method argument) for the conditional to determine within range.
Tho, I would only do it if it were necessary. But that would be neat
I find final in your example to be totally superfluous since all parameters should always be final following good code practice. Why on earth would you want to reassign the parameter reference? So instead of writing final on each and every parameter, just assume it is (yes, it ought to be the default).
For that matter, most variables should be treated as final as well. Consider this (ridiculous) example:
The first line is a lie! Here’s a better way to do it:
Thank you very much for this article.I like its.As to me it’s good job.
Look for the white iphone 4 avaiable online store? We may search on net for what you need.
I find final in your example to be totally superfluous since all parameters should always be final following good code practice. Why on earth would you want to reassign the parameter reference? So instead of writing final on each and every parameter, just assume it is (yes, it ought to be the default).accounting services
i need this code thanks a lot for sharing…
internette görüntülü olarak okey oyunu oyna, gerçek kisilerle tanis, turnuva heyecanini yasa.
We may search on net for what you need.
you best choose fashion Louis Vuitton Damier Azur Stresa MM onsale.The Best Site to buy CHEAP Louis Vuitton Damier Azur Stresa PM .Also has Louis Vuitton Damier Azur Canvas Neverfull MM, Louis Vuitton Pochette Milla MM outlet that can provide to you.
The Monster Beats By Dr. Dre Studio Headphones are classic shoes.You will be proud of owning them. Don’t hesitate!Take Monster Beats By Dr. Dre Pro home! Choose our Monster Beats By Dr. Dre Solo Headphones will make you have an amazing discovery.
Have the christian louboutin patent leather pumps is a happy thing. Here have the most complete kinds of christian louboutin leather platform pumps.
Hello Friend,Whichever style of Fashion Shoes you’re looking for, classical, fashionable, lovely or the latest design, you can find your favorite designer shoes in www.dunkpage.com ,several days ago I bought one pair of shoes from there,It’s beautiful and very comfortable!
When work is a pleasure , life is joy ! When work is duty , life is slavery .
Why not keep the data more safe on computer by backuping them?