This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Not too bad! You have Javadoc style comments inside the method, which you don't need. They won't show up in the Javadocs anyway. Maybe rename d to something more descriptive? That's being a bit picky. Style-wise everything else looks fine. I think the algorithm is wrong though. You don't mean to divide both x and y by the common factor, do you? That would result in too low of an answer.
Looks good to me also. If it was my code, I'd use longer variable names (probably...in math-heavy code I don't always ). Also, I'd move the "final possibility" clause to the very start - this is much more efficient, you can avoid the main body algorithm.
Finally, I'd consider using Euclid's Algorithm for finding the LCM. It's very efficient, and not too complex. Dunno if efficiency is a concern though.
--Tim [ June 30, 2004: Message edited by: Tim West ]
Ryan, Looking good man! Greg had good suggestions about the comment type and variable name. Use inline comments within methods. Use descriptive variable names. For other good tips on Java coding style, I recommend the book Elements of Java Style (Vermeulen et al.).
Mala, as with most style guidelines, Greg's suggestions are based on code clarity and readability. As software developers, one of our primary concerns is how well our code communicates its intention. Nested loops are by nature more difficult to comprehend. Sometimes break and continue are useful, but one should take care to make them obvious in code because they violate the normal flow of looping control structures.
Greg, your version of the LCM algorithm looks great, but upon cursory inspection I would have to delete that second-to-last line. Am I wrong?
Originally posted by Nick Knickerbocker: Greg, your version of the LCM algorithm looks great, but upon cursory inspection I would have to delete that second-to-last line. Am I wrong?
Yes, you are wrong. The loop only makes x and y relatively prime. That is, it pulls out their common factors and stores them in a running tally. (No, tally's not the right word. Running product?) If x and y started relatively prime, for example 4 and 15, the running product after the loop would be 1, and x and y still the same. Ah, but maybe you were thinking of greatest common factor?