The sad part is that many Java programmers would probably not realise that this is supposed to be a parody, because there are even more ridiculous-looking things in real, "production" Java code:<p><a href="http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html" rel="nofollow">http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...</a><p><a href="http://docs.spring.io/spring-framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html" rel="nofollow">http://docs.spring.io/spring-framework/docs/2.5.x/api/org/sp...</a> (this one is somewhat famous - maybe it wins the "most number of design patterns in a class name" award?)<p>The impression I get whenever I come across code like this is that its authors were more interested in "creating architecture" than solving a real problem - and creating many classes containing short methods whose only function is to create more objects or pass existing ones around is a particularly insidious form of busy-work.<p>GNU Hello (<a href="http://www.gnu.org/software/hello/" rel="nofollow">http://www.gnu.org/software/hello/</a> ) is basically the same sort of thing done to a Hello World program.
They rejected my pull request to migrate their markdown docs to docbook.<p><a href="https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/pull/125" rel="nofollow">https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...</a>
I love that there is a commit to 'remove redundant import'. <a href="https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/commit/3732e43bc59070e5f1c9e826d07b6313453d42cd" rel="nofollow">https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...</a><p>Being enterprise software, the last thing they need in the codebase is clutter.
The sad part is that there is actually an advantage to abstracting out the printing of fizz and buzz, and that is it will be easier to test. But the authors didn't even swap in a testable printing strategy, they just changed System.out.
The main thing I look for with FizzBuzz solutions in general is how many modulus operators are used. The junior end of the spectrum tends to use four (% 5 && % 3; % 5; % 3), while intermediate/seasoned developers will either use three (% 15; % 5; % 3), or two (storing % 5 and % 3 in variables, then comparing the combinations).<p>My personal preference in terms of demonstrating maintainable code is using two modulus operations with variables. However, I fully understand the argument that an additional % 15 is preferable compared to the overhead of storing two variables on each iteration. Both are valid approaches IMO, and the debate can roar on for eternity. Micro-optimizations and whatnot.<p>I just don't like to see four modulus operations, which IMO shows a lack of basic willingness or ability to refactor while coding. It's fine to initially write the four modulus operations, but if someone doesn't immediately catch the duplication and do something about it, it screams "I write code until it works and then move on without cleaning anything up."<p>Strangely enough, only once have I seen someone use the % 15 optimization <i>and</i> add a short comment along the lines of "// least common multiple, divisible by both 3 and 5". Spotting the optimization is nice; placing a short comment explaining why % 15 when the test is about % 5 and % 3 is a nice touch. Explains something that might not be immediately obvious to the next person coming to the code.<p>Aside: it astounds me how many people, when asked to write a short snippet of code during an interview, have basic formatting problems and inconsistent code style. I've seen two lines of code inside an if() block indented at different levels, with no excuse for "different opinions on formatting". Not a wrapped line continued on the next, but just two simple statements inexcusably indented at say 8 and 12 spaces. Don't call us, we'll call you...
"... necessary tools such as if-/else-statements and loops"<p><a href="https://en.wikipedia.org/wiki/Array_programming" rel="nofollow">https://en.wikipedia.org/wiki/Array_programming</a>
Enterprise programming is like Hadoop. Huge startup overhead, but once workers start up, progress shoots up at a pace faster than possible with less thought out systems.