The problem I face, actually already for quite some time now, is that during the design of an API I am forced to capture the functionality of a method in a short but meaningful way. It amazes me that I often find myself spending more time on thinking about a suitable name for a method than on writing the actual code. My main question : what are your best practices on picking suitable names during the design of your API? Do you use some kind of list of prefixes that you reuse over and over again or .... [ June 07, 2008: Message edited by: Arnold Reuser ]
An alternative approach is not to design the API, really, but instead write some client code that uses the API before it even exists. In the client code, name the imaginary methods you're calling according to what they do from the client perspective. This is often called "programming by intention", and it often leads to APIs that are simple and intuitive to use.
Originally posted by Arnold Reuser:My main question : what are your best practices on picking suitable names during the design of your API? Do you use some kind of list of prefixes that you reuse over and over again or ....
Java is not C vintage 1990, there is no need for Hungarian notation.
Pick names that make sense, good IDEs can do expansion for you, so saving a few characters is not needed or even good. Think about the developer who has to use the code five years from now.