This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
The discussion has been about introducing identifiers into boolean expressions, but I wonder if that is actually the best approach here. If you start with this:why not begin by simplifying it to this:Then reduce (fooValue > 10) && (fooValue > 80) to just (fooValue > 80), which gives:For greater clarity, I would be tempted to lay it out like this (omitting one set of parentheses that, IMHO, add nothing):Now you could introduce some constants, as Stan suggests.
So I am not disagreeing with what has been said about introducing identifiers, but I don't believe that it would be the best approach in this particular case. The meaning of the last expression above is, to me, extremely clear.
Joined: Feb 03, 2005
OK then�this is what I love about these forums. Finding out how many ways there are to skin a cat (Btw... I'm a lurker here... I come in and read just for the fun of it.)
The expression I posted bears a vague resemblance to the actual expression in my program. Being an exercise from the drive, I can't post the actual code for fear of severe beating by various nitpickers and, frankly, I have enough bruises as it is.
Before I posted, I had considered all the options presented in the replies; but I needed a bit of validation as to whether or not I was on the right track. It's good to know that my instincts are intact, even after 10 years of green screens and procedural languages.
Here's what I considered with respect to the actual code:
1) Define constants for the values on the right side of each expression. I discounted this because these values really have no meaning by themselves and would not make the logic any more understandable.
2) Introduce identifiers for the left side of each expression. Again, by themselves for the actual code, these have no real meaning.
3) Combine 1 and 2. The logic is no more understandable, probably even more confusing.
4) Introduce an identifier for each expression in its entirety. This seemed to make the most sense to me, but I wasn't quite sure how to go about it. When I saw Ernest's examples, I saw the light. (Btw, Ernest, the simplicity of those sample methods made me simplify some code in my next exercise. It's amazing how one good example can cause an epiphany!)
Anyhow� at the risk of being beaten, I'll share with you the actual names of the methods I created for approach #4: