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.

Freitag, 17. Februar 2012

The need for a classification of documenation artefacts

Today I had a very interesting discussion with my colleague Jarek concerning iDocIt!. During the discussion the question came up whether the interface is the right place for some of the documented characteristics of the operation, e.g. test cases formulated by the tester. I remember that I was confronted with this question in many discussions over the last months.

From my point of view there is a real need for a systematic of
  • which places / artefacts exist in a project containing documentation?
  • which kind of documentation contents exist?
  • which content should be stored in which artefact?
Yet, we don't support such systematic with iDocIt!. I am very interested in the opinion of the you readers on this topic: did you see and use such systematic in your projects?

Mittwoch, 15. Februar 2012

Avoiding Redundancy in Specifications

I have the impression that some colleagues feel a bit strange in certain situations when specifying in interface. And it is the same with me ;). This feeling comes up, when I formulate something in natural language which is obvious from the corresponding identifiers. But the conventions (e.g. the Javadoc Guidelines) force me to do so. Consider the following example:

/**
 * Returns the customer with the given id or <code>null</code>, if
 * no record is found.
 * 
 * @param id
 *            The id to look for
 * @return The found customer or <code>null</code> 
 */
public Customer findCustomerById(Integer id);

This simple example contains a lot of redundant information:
  1. The first part of the introduction sentence (until the conjunction "or") repeats what the identifier of the operation says. 
  2. The second part of this sentence tells something, what is also mentioned in the @return-tag.
  3. And finally the explanation of the parameter id is also obvious, isn't it ;).

I think, this kind of redundancy is real noise (see Bertrand Meier's great essay "On formalism in Specifications" for further reading). It prevents us from reading the new and important information, in this example the null-behaviour. So, what to do?

To answer this question I would like to know which information should be included in the specification. Then I would assign this information to the different parts of the spec (e.g. the @param-tag). To derive such information, I use the approach of thematic grids which is implemented in iDocIt!. I classify the given operation as a "Searching Operation". The corresponding thematic grid asks me to document the following information:

ACTION: What is done?
OBJECT: What is searched?
SOURCE: Where is searched?
PRIMARY KEY: How is the searched OBJECT identified?

Let's answer these questions:

ACTION: Find the customer with the given id
OBJECT: The customer
SOURCE: The database of our customer relationship management system
PRIMARY KEY: Parameter id

From my point of view, the identifier of the operation explains very well what the operation does. And it also contains the searched OBJECT. I think no further comments are needed. But the Javadoc guidelines force us to formulate an introduction sentence explaining what the operation does. I suggest to explain here, where the operation searches (thematic role SOURCE). From my experience it is always a good idea to explain the null-behaviour only in the @param- and @return-tags. This would lead to this refactored version of the specification:

/**
 * The source of the returned customers is the customer relationship 
 * management system operated by the customer care department.
 * 
 * @param id
 *            Primary Key. <code>null</code> is not permitted here.
 * @return The found customer (object) or <code>null</code> 
 */
public Customer findCustomerById(Integer id);

So, I conclude when specifying an interface one should follow these (rough) steps:
  1. Classify the operation and identify which information needs to be documented (e.g. by using the thematic grids of iDocIt!).
  2. Fill the thematic grid precisely.
  3. Identify which information are already expressed by the identifiers oder could be expressed by identifiers. Strike them from the grid and rename the identifiers, if necessary.
  4. Formulate the remaining information as specification, e.g. in Javadoc.
From my experience: for the parameters and return-values there is always the possibility to restrict the set of allowed values. It is also a useful information, if all possible values are allowed (e.g. for an int in Java).

Montag, 13. Februar 2012

Should I specify every interface?

In many discussions about iDocIt! people raise the question on the added value of specifying every interface (e.g. a Java Interface) in every project? This is a good and reasonable question. 

Personally I made the experience that it is quite helpful to reflect own thoughts, especially when writing software. To be honest, this is my motivation to specify an interface. Such reflections of own thoughts could be done by writing pseudocode on paper, writing unit tests or when specifying an interface in the code. But it costs time and, as we all know, this resource is strictly limited ;).

I think, that interface specification has an added value under one of these conditions:

  • The interface provides complex operations and one has to think about them carefully (for reasons see the above paragraph).
  • The interface is provided to developers in other organizations (e.g. another project, division or even another company). For two reasons: 
    1. The colleague who implemented the interface is not or rarely reachable.
    2. To avoid argues ("Who has to catch the null-reference and who pays for it? The implementing company or the invoking one?")
  • The system is going to be run a lot of years and one could assume that some colleagues will leave the team or even the company.

Donnerstag, 9. Februar 2012

Some thoughts on "minor" identifiers

Today I realized something interesting: I wrote a function in Python which should convert a list of booleans into a string with a specific format.The string is used to generate an image visualizing a chart. Because it is a compressed form of the boolean list, I call it "shrinked string". I thought about the identifier of the function and got something like this (in Python syntax)

def convert_to_shrinked_string(boolean_list):

But I was very happy with this because I had the strong feeling that this identifier would be unusual. I can not explain this feeling, it just was there. After some tries I had this idea, which I was quite happy with:

def as_shrinked_string(boolean_list):

I saw this kind of identifiers in the official Java Class Libraries:

Arrays.asList()
Collections.asLifoQueue()

It seems that it is quite useful and common to leave out the verb in some cases. I have seen that in only in cases of "Converting Operations" yet (if you know one other, please tell me via a comment ;)). But, what implications does this have for iDocIt!? iDocIt! extracts its suggestions on aspects to document from the verb of the identifier and won't work without a verb.

On a conceptual layer this is not a problem, because sentences without a verb exist also in linguistics. These sentences are called "minor sentences", e.g. "Great!" or "Yes, please". In these examples the verbs have been omitted due to shortness and convenience. But both sentences could be completed by a subject and a predicate such as "That is great!" or "Yes, please do it". I believe it is the same with the minor identifiers. One could say that "as_shrinked_string(...)" is the short form of "convert_to_shrinked_string(...)" or "get_as_shrinked_string(...)". So, the verb-centric concept of iDocIt! covers this kind of identifiers. But it is not supported in the current version of iDocIt!.