The 2 vote was another mistake of mine, sorry for that. I wanted to go to page 2 to see the original post, clicked the vote 2 instead, and forgot to make the correct vote to your post. I've just corrected it with the vote it really deserves, a 5. I know my final logic does the same as the original but is slower. It is obvious. And it is much clearer, and this is also obvious. The sample I give just before does the same also, and is faster. Both of them improve the original in readability, and the first one also improves it in speed. If you had to manage a team of developers, some of them newcomers with very little experience, tell me, having the original code and the two samples I am giving, which one would you choose? I would choose the last one, though I know it is slower, but I also know that the overhead is just negligible in this case, becouse this operation will not be used over and over again within de context of a long and complex batch process. I don't mind to have several "return" in the same method... if it improves readability and/or performance. In the case presented here, it does not improve readablity neither performance, so that is the reason why I consider it a horror. Nobody is obligated to agree, I am just sharing my point of view. Edit Sorry again, I was forgetting the las part. The implementation for bitdepth and refreshrate is given just before, but like you wonder how they should be, I will give some extra clues:
return mode1.getWidth() == mode2.getWidth() && mode1.getHeight() == mode2.getHeight() && // This checks sizes
(mode1.getBitDepth() == mode2.getBitDepth() || // These three lines
mode1.getBitDepth() == DisplayMode.BIT_DEPTH_MULTI || // are checking if
mode2.getBitDepth() == DisplayMode.BIT_DEPTH_MULTI) // bit depths match
&&
(mode1.getRefreshRate() == mode2.getRefreshRate() || // These three lines
mode1.getRefreshRate() == DisplayMode.REFRESH_RATE_UNKNOWN || // are checking if
mode2.getRefreshRate() == DisplayMode.REFRESH_RATE_UNKNOWN); // refresh rates match
Thank you
modified on Tuesday, October 19, 2010 9:28 AM
