Anti-pattern, what a cool name. It wouldn't be enought to call it just stuff you shouldn't do. This entry is in the same sarcastic vein as How to Write Unmaintainable code. That's a great website, every code slinger should read it. While you're looking for something to read, go read Effective Java by Joshua Bloch. He wrote lots of the Sun Java APIs and points to some warts in some other Sun APIs (presumably ones he didn't write).
Return an un-typed collection like a Vector and don't document the return type This isn't as much of a problem now that Java lets you type your collections. Everyone should take advantage of this. If you do this without putting specifics in the JavaDocs you have a special level of hell reserved for you.
Require a Properties to make your system usable What goes in the Properties object? I'm looking at JavaDoc right now and they tell you what goes into the Properties object by referring to another specification. ....arrr! A Properties object is basically a HashTable that can have any String (usually a constant tucked away somewhere else in the API) as a key and any String as a value. After my IDE and I look at each other shrugging our shoulders we begin the journey down the rabbit hole to figure out what goes in your Properties object. What is this buying us? A well documented bean-like object with setters and getters would be better.
Use integers for constants The primitive int is nice and small and you don't have to feel bad when you're sending it around to handle constants. It's no fun having to debug or maintain code and look at log entries and see a beautifully expressive "3" sitting in your logs. Maybe it'd be better to see a String with something like "SYSTEM_OFFLINE" or an enum that has it's own description attribute? If you're not using Java 1.5 enums you should read up on using typesafe enums as recommended by Joshua Bloch in his book Effective Java. When using enums liberally provide descriptions about what they mean, these can be used programmatically to make your API self documenting.
Instantiation Gymnastics The factory pattern has to be a good thing right? It has a name and smart people use it. I contend that it is over-used. Perhaps dependency injection could get rid of 80% of instances of factory patterns in the wild. It's hard to get respect in a room full of geeks when you're the guy saying, "should it really be this complicated." But really, should using an API be this complicated? I remember reading a Perl hacker ranting about how he can write a functional Perl script in the time it takes a Java coder to get an instance from an abstract factory singleton after passing in some esoteric properties, yada, yada. He had a point.
Use Random Naming Conventions Why settle for just get[Noun], how about find[Noun], retrieve[Noun], read[Noun]. The opportunity is endless for confusing the users of your API. I like to write a BNF document for the naming of the public methods in my API and make sure I'm sticking to my own rules. For a persistence API maybe the BNF rules would look something like this. methodName ::= [verb][noun] verb ::= create|read|update|delete noun ::= Account|User|Location
Don't Practice Test Driven Development Just because TDD is a TLA doesn't mean it's lame. For the un-initiated test driven development means writing the tests for your API, maybe even before you write an interface. IDEs like Eclipse can make this an interesting experience when they offer to create the interface you are coding to on the fly; slick stuff. Doing TDD makes you the first customer of your API. You get a chance to see if your API even remotely makes any sense to someone using it. By doing this first you have less invested in a crappy design and are more likely to tweak it.
Don't Offer a Sensible toString() There's nothing more heart-warming than hoping you'll find out the current state of an object only to see it's location in memory. To someone somewhere I'm sure this is helpful. In an externally exposed API I say it's un-forgiveable. There's no excuse, you should have toString() implemented for your own use nevermind being useful for others. Worst case you can use the Jakart Commons ToStringBuilder that uses reflection.
Use Verbose Javadocs Complete With Cool Formatting Javadocs, as with well named methods should just say what a method does not how it does it. If you have code that is so confusing that you need to explain how it does something first consider pulling out some of the functionality into another well named method. I'm going off on a tangent, that's not stuff an API user sees. The point here is that if you write a long multi-paragraph javadoc along wiht some cute formatting you are quickly decreasing the likelyhood that the javadocs will be maintained. As a maintainer just trying to refactor code or fix defects you don't want to spend 10 minutes absorbing your long comments, re-writing them and possibly re-formatting them. So, keep it short, if you've written your API such that you need long comments think hard about how you can improve the usability of your API.
Show the World How Sausage is Made No one wants to know all the ugly things you're calling or have exposure to all of your dependencies. This makes the calling system coupled to the same crap your API is coupled to. This is of course referring to the law of demeter. The bottom line is that if you expect your API users to do something like this: boolean isNorthAmerica = yourObject.getEmployee().getAddress().getCountry().isNorthAmerica();
...that's a bad thing.
Anti-pattern, what a cool name. It wouldn't be enought to call it just stuff you shouldn't do. This entry is in the same sarcastic vein as How to Write Unmaintainable code. That's a great website, every code slinger should read it. While you're looking for something to read, go read Effective Java by Joshua Bloch. He wrote lots of the Sun Java APIs and points to some warts in some other Sun APIs (presumably ones he didn't write).
Return an un-typed collection like a Vector and don't document the return type This isn't as much of a problem now that Java lets you type your collections. Everyone should take advantage of this. If you do this without putting specifics in the JavaDocs you have a special level of hell reserved for you.
Require a Properties to make your system usable What goes in the Properties object? I'm looking at JavaDoc right now and they tell you what goes into the Properties object by referring to another specification. ....arrr! A Properties object is basically a HashTable that can have any String (usually a constant tucked away somewhere else in the API) as a key and any String as a value. After my IDE and I look at each other shrugging our shoulders we begin the journey down the rabbit hole to figure out what goes in your Properties object. What is this buying us? A well documented bean-like object with setters and getters would be better.
Use integers for constants The primitive int is nice and small and you don't have to feel bad when you're sending it around to handle constants. It's no fun having to debug or maintain code and look at log entries and see a beautifully expressive "3" sitting in your logs. Maybe it'd be better to see a String with something like "SYSTEM_OFFLINE" or an enum that has it's own description attribute? If you're not using Java 1.5 enums you should read up on using typesafe enums as recommended by Joshua Bloch in his book Effective Java. When using enums liberally provide descriptions about what they mean, these can be used programmatically to make your API self documenting.
Instantiation Gymnastics The factory pattern has to be a good thing right? It has a name and smart people use it. I contend that it is over-used. Perhaps dependency injection could get rid of 80% of instances of factory patterns in the wild. It's hard to get respect in a room full of geeks when you're the guy saying, "should it really be this complicated." But really, should using an API be this complicated? I remember reading a Perl hacker ranting about how he can write a functional Perl script in the time it takes a Java coder to get an instance from an abstract factory singleton after passing in some esoteric properties, yada, yada. He had a point.
Use Random Naming Conventions Why settle for just get[Noun], how about find[Noun], retrieve[Noun], read[Noun]. The opportunity is endless for confusing the users of your API. I like to write a BNF document for the naming of the public methods in my API and make sure I'm sticking to my own rules. For a persistence API maybe the BNF rules would look something like this. methodName ::= [verb][noun] verb ::= create|read|update|delete noun ::= Account|User|Location
Don't Practice Test Driven Development Just because TDD is a TLA doesn't mean it's lame. For the un-initiated test driven development means writing the tests for your API, maybe even before you write an interface. IDEs like Eclipse can make this an interesting experience when they offer to create the interface you are coding to on the fly; slick stuff. Doing TDD makes you the first customer of your API. You get a chance to see if your API even remotely makes any sense to someone using it. By doing this first you have less invested in a crappy design and are more likely to tweak it.
Don't Offer a Sensible toString() There's nothing more heart-warming than hoping you'll find out the current state of an object only to see it's location in memory. To someone somewhere I'm sure this is helpful. In an externally exposed API I say it's un-forgiveable. There's no excuse, you should have toString() implemented for your own use nevermind being useful for others. Worst case you can use the Jakart Commons ToStringBuilder that uses reflection.
Use Verbose Javadocs Complete With Cool Formatting Javadocs, as with well named methods should just say what a method does not how it does it. If you have code that is so confusing that you need to explain how it does something first consider pulling out some of the functionality into another well named method. I'm going off on a tangent, that's not stuff an API user sees. The point here is that if you write a long multi-paragraph javadoc along wiht some cute formatting you are quickly decreasing the likelyhood that the javadocs will be maintained. As a maintainer just trying to refactor code or fix defects you don't want to spend 10 minutes absorbing your long comments, re-writing them and possibly re-formatting them. So, keep it short, if you've written your API such that you need long comments think hard about how you can improve the usability of your API.
Show the World How Sausage is Made No one wants to know all the ugly things you're calling or have exposure to all of your dependencies. This makes the calling system coupled to the same crap your API is coupled to. This is of course referring to the law of demeter. The bottom line is that if you expect your API users to do something like this: boolean isNorthAmerica = yourObject.getEmployee().getAddress().getCountry().isNorthAmerica();