Sonntag, 11. November 2012

Describing Attributes of Classes

In many of the classes I saw over the last years were no comments to describe the attributes or member variables. The most frequently used style of commenting attributes from my experience is reformulating the variable-identifier in natural language. Consider the following Java-class as an example:


public class Invoice {

 /**
  * The order
  */
 private Order order;

 /**
  * The invoicing amount
  */
 private double invoicingAmount;

 /**
  * The id
  */
 private int id;

 /**
  * The due date
  */
 private Date dueDate;

 [...]
}

I believe that these comments will help nobody, because they are just redundant and contain no further information. But how to do it better? 

Well, in English one could describe the overall and general meaning in form of clauses. A clause is the simplest grammatical unit that can express a "meaning". There are several forms of clauses, e.g. relative ("I like the car, which is red.") or temporal ones ("After cleaning the house, please wash the car.").

I made the experience, that a simple patterns fits the problem of commenting attributes. You can use the main clause "This attribute represents ..." + CLAUSE. Since the main clause is always that same, you can omit it and just write the relative or temporal CLAUSE into your code. Look, how this pattern applies to the example from above:

public class Invoice {

 /**
  * What the customer has to pay for
  */
 private Order order;

 /**
  * What the customer has to pay including all discounts.
  */
 private double invoicingAmount;

 /**
  * What is used to find/identify this invoice.
  */
 private int id;

 /**
  * When this invoice has to be paid.
  */
 private Date dueDate;

 [...]
}

All of these clauses have the type of an content clause. They have the same role as an object. These clauses simply replace the object noun. I think, these comments express explicitly the general purpose the attributes. So we have an added value. When formulating it with clauses, this seem to come automatically. 

Please let me know if this patterns works for you :).

Donnerstag, 18. Oktober 2012

Interesting talk with Dave Parnas about documentation

I just found a very interesting podcast with Dave Parnas about the issue of documentation and why code often is not selfexplaining here.

Dienstag, 11. September 2012

Slide of my talk at DevCon Hamburg 2012 online

I uploaded the slides of my talk at the Developer Conference 2012 in Hamburg on SlideShare. I am looking forward your feedback :).

Sonntag, 26. August 2012

Using Sun DocCheck for Java

Today I tried to get the Sun DocCheck tool up and running on my Macbook. Yes, I know that Checkstyle covers even more than this tool. But I needed to have a look at it because of research for my doctoral thesis. I would like to describe my trip through the javadoc-valley-of-tears in this post. Maybe it is useful for some of you out there :).

  1. Download the doccheck.jar here. The links on the official Oracle Homepage don't seem to work.
  2. DocCheck requires the class com.sun.tools.doccheck.HtmlWriter. This class is no longer included in modern JDKs. So I downloaded the Java 1.2 SDK for Windows, installed it on my Windows machine and took the tools.jar from this installation. Save this JAR in the same directory as doccheck.jar.
  3. Put the tools.jar into the classpath: export CLASSPATH=tools.jar
  4. Call the javadoc-command with the doccheck doclet:
javadoc -doclet com.sun.tools.doclets.doccheck.DocCheck -docletpath doccheck.jar -sourcepath <PATH_TO_YOUR_CODE> -d <OUTPUT_DIR> -subpackages <YOUR_TOPLEVEL_PACKAGE>

Montag, 30. Juli 2012

Best practices for writing API documentation

Yesterday I found a great blog post from Mark Tattersall via Twitter. It is about best practices and patterns for writing API documentation he identified when improving his own API at Braintree. Thank you Mark for your great work ;).

Montag, 23. Juli 2012

Why should I write comments?


Nearly everytime when talking about commenting interfaces or source code, the question "why documentation?" is raised. I realized that there are a lot of different motivations for writing some comments in natural language. My personal one is that I use writing in natural language as a tool to reflect my own thoughts. If I am not able to explain or formulate something, this might indicate that my solution is not ready right now.

So why should I write a contract for an operations? In this posting I try to collect some reasons for writing a contract. Here is my current list:
  • Reflect my own work or thoughts
  • Specify a task (for another person)
  • Get juristic safety when providing software-operation to another, external organization (e.g. another company).
  • Define what an operation should do (e.g. for later maintenance: its easier to decide if the implemented operation does things correctly)
  • Agree with somebody else on an operation and work in parallel on it (more precise as only with code)
  • To be continued ...
Feel free to post your reasons with a comment :). I am very excited to read them.

Sonntag, 22. April 2012

How to classify an operation?

When documenting APIs with iDocIt!, you classify each documented operation. There are several categories such as Searching Operation or Mathematical Operation. This classification is easy when the classified operation does only one activity, e.g. computing a value. From my experience, you will find such cases rarely in your daily business.


Right now I develop a new extension for iDocIt!'s Java support. With this extension it is possible to generate a very compact Javadoc-representation of iDocIt's thematic roles. When implementing JUnit-Test cases for it I had to document (and classify) this method:


/**
 * Adds a new {@link Documentation} with the given attributes to the given
 * {@link SignatureElement}.
 * 
 * @param element
 *            [DESTINATION]
 * @param addresseeName
 *             [ATTRIBUTE] Used in the new documentation
 * @param thematicRole
 *            [ATTRIBUTE] Used in the new documentation
 * @param docText
 *            [ATTRIBUTE] Used in the new documentation
 * 
 * @thematicgrid Putting Operations
 */
public static void addDocumentation(SignatureElement element, String addresseeName,
String thematicRole, String docText)
{
 List<Addressee> addressees = createReferenceAddresseeList(addresseeName);

 Map<Addressee, String> docs = createComparisonDocumentation(addresseeName);
 docs.put(addressees.get(0), docText);

 Documentation documentation = new Documentation();
 documentation.setAddresseeSequence(addressees);
 documentation.setThematicRole(new ThematicRole("COMPARISON"));
 documentation.setSignatureElementIdentifier("records");
 documentation.setDocumentation(docs);

 element.addDocpart(documentation);
}

As you see, the method creates a new instance of Documentation and then adds it to the given SignatureElement. From my point of view, it's first part should be classified as Creation Operation and the last row is a Putting Operation.

Due to my posting Second extension of my thoughts ... I would classify this operation as Putting Operation, because its final goal is to add a documentation to the given SignatureElement. I think, this rule could be generalized:

If you have an operation composed of several operation categories, choose the last one as catgeory for the composite-operation.