Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Very nice article and good job on the classification of comment types.

For small tools that I have written myself I prefer the guide comments because I usually know the general design of the program but need some help to remember the order of the things done inside a function/procedure/method. But the more complex the application, the more higher-level comments are needed.

Note that the guide comments can also appear in the form of function comments. For example, you see sometimes the networking function written like this:

    ...
    logLinkDisconnectionWithReplica();
    freeQueryBuffer();
    deallocateBlockingStructures();
    ...
In that case the the function comments of the called functions are actually the guide comments (edit). I have the impression that this style of programming is popular among smalltalkers (please correct me if I am wrong).

It is also interesting to see how the comments depend on the expressiveness of the programming language. For example, you can see a lot of "trivial" comments in assembly code because even simple things (like incrementing a counter) sometimes need code that is not easily readable. In Java, you see less comments like "This method throws an IllegalArgumentException if ..." because the programmer thinks that the list of checked exceptions in the method defnition are sufficient. In a language that I just made up for this comment, a procedure with signature

    getPerson : (name : String not empty) -> List(Person) not empty | Nothing
needs less function comments than

    struct list *getPerson(char* name)


While true, even staying in the realms of straight C that function could have been improved.

    typedef struct list *person_data_list;

    person_data_list getPerson(const char const *name);
Yes it still does not provide all the necessary information, but it already does provide a bit more.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: