You should use the square root of n, not n / 2. And try to avoid value of 0 or 1 for i, since ArithmeticExceptions are annoying, and the fact that n % i is always 0 will give you an out-by-one ( ) error.
I think yes. I know other people will disagree, however.
It can be confusing and more difficult to maintain to have multiple returns. And remember that in structured programming you can always, but always program everything with multiple sequence repetition and selection.
Sorry for the isPrime mistakes ; was trying to whip up a quick example.
@Bear - I was asking about return the boolean values true/false. It was something one of my friends was telling me, he said that apparently it was a bad practice; I had never heard that before, so I wanted to check.
None that I could find on the internet, so that's why I posted here . It could be that he was complaining about the multiple returns I was using, but from what he said it seemed to me he was saying that returning the booleans without storing them locally was a bad practice.
It could be that he was talking about a case like this:
Many of us would prefer to write this as
simply because it's shorter. But that only works if you're returning something on both branches of the if statement. In your first example above, you return on only one branch each time, and continue with the method otherwise. So the trick I just showed doesn't work. I would say your original code with multiple returns is fine - though Campbell's point about using Math.sqrt() is a good one, and the first if statement isn't necessary if you start the index at 2 as Campbell did:
To me, the multiple returns above are slightly more readable than the code Campbell gave with the extra boolean condition. But often, readability is just a matter of what you're used to.
Note that I also avoided recalculating Math.sqrt() each time through the loop. Then again, there are plenty of additional optimizations possible for a good industrial-strength prime checker, and that's beyond the scope of what you probably intended as a simple example.
Sounds like he meant the multiple returns, then. Some people consider it bad practice to have multiple exit points from a method.
Personally I think that's overstated. Having multiple returns can be confusing, but there are other occasions when it's clearer than the alternative - and clear code is really the aim here.
I'd see it more as a potential warning flag. If you're using multiple returns, just take a second to ask yourself if your code is as clear as it could be. If rearranging it to have a single return would make it clearer, do it. If not, don't worry about it.
Joined: Mar 05, 2008
Hunter McMillen wrote:None that I could find on the internet, so that's why I posted here . It could be that he was complaining about the multiple returns I was using, but from what he said it seemed to me he was saying that returning the booleans without storing them locally was a bad practice.
Ah, now that I've read that, I don't think he was talking about my if-condition-return-true-else-return-false example. Oh well. Then I'll simply say I agree with Bear on this one. Sorry, Campbell.
Joined: Oct 13, 2005
I earlier wrote:. . . I know other people will disagree, however. . . .
For balance, I was going to link to an article arguing the opposite. I couldn't actually find one though. All the (vaguely recent) ones I could find (in a quick search) were saying "some people say that multiple returns statements are bad, but I disagree because...". Nobody standing up for the structural purists!
There's nothing wrong with returning true or false directly. There's no reason to store the values somewhere first before returning them. Mike Simmons makes a good point about just doing return condition; instead of if (condition) return true; else return false;.
Having multiple returns can lead to bugs, I've experienced that myself a few times. For example, I worked on a system that had to do with the railways, which contained a lot of business logic to find trains in the system, the matching carriages, train schedule etc. I don't remember all the details exactly (it's been more than a year ago that I worked on that software), but there was a lot of searching and matching of objects in collections. Suppose there would be a method that looks like this (not an actual method from the source code):
There were a number of early returns in the method.
One day, new features had to be added, which meant that some more processing on the list of carriages had to be done. Initially, we just added the additional processing to the end of the method. During testing we discovered that the additional processing was sometimes not done. The cause was those early returns: other logic in the method would do an early return under certain circumstances and skip the additional processing. We had to meticulously go through the code again to make sure that it would do the additional processing at the right time.
If there wouldn't have been all those early returns, it would probably have been easier to add the new functionality, and we wouldn't have had the bug.
Bear Bibeault wrote:The question is on the practice of return boolean, not using multiple returns.
The original post had returns in the middle of a for loop, which looks like multiple return to me. I agree this sort of thing . . . is an abomination, and it looks even worse if you realise the "else" is redundant and write