Introduction

General programming topics like documentation, naming and UML.

Archive for the ‘Progr. in General’ Category

Wednesday, April 14th, 2004

Documentation

I’m currently documenting all classes of the as2lib. Good documentation is often neglected in the world of ActionScript. Although it is very important. Thus here a few guidelines.

Why should I document code?
It’s quite easy to answer this question. Others too wanna know what’s going on or how they can use the code. And that without rummaging through all the stuff. But it’s also a help for you. Imagine you write a piece of code and years later you need to use it. You probably don’t know anymore how to work with it. And without good documentation you had to spend maybe an hour to just get the whole thing to work.

How do I document?
There exist a few standards. These standards are actually from a Java background but you can use them in every language. It’s important to pay attention which standards you documentation tool uses to extract the documentation properly.
The follwing link may be useful: http://java.sun.com/j2se/javadoc/writingdoccomments/.
Let’s start:

The Basic Construct:
/**
*
*/

That’s the basic construct. You probably know it. Just use it for every doc comment.

Block Tags:
Block tags are tags preceded by an @. The one you do probably need at most are: @param, @return, @see, @throws, @author and @version. There do exist more. You can find them with a big description under the link I posted above.

How a Doc Comment is Made Up:
/**
* [description]
*
* [block tags]
*/

Example:
I’ll just use the example from the above link because it is (almost) perfect:

  1. /**
  2. * Returns an Image object that can then be painted on the screen.
  3. * The url argument must specify an absolute {@link URL}. The name
  4. * argument is a specifier that is relative to the url argument.
  5. *
  6. * This method always returns immediately, whether or not the
  7. * image exists. When this applet attempts to draw the image on
  8. * the screen, the data will be loaded. The graphics primitives
  9. * that draw the image will incrementally paint on the screen.
  10. *
  11. * @param  url  an absolute URL giving the base location of the image
  12. *         name the location of the image, relative to the url argument
  13. * @return      the image at the specified URL
  14. * @see         Image
  15. */
  16. public Image getImage(URL url, String name) {
  17.     try {
  18.         return getImage(new URL(url, name));
  19.     } catch (MalformedURLException e) {
  20.         return null;
  21.     }
  22. }

I’m sorry for the bad design (no spaces etc.) but MovableType screws the whole thing up. If you know how to fix it let me know.
[Edit]The spaces work now. At least in the example.[/Edit]

Monday, April 12th, 2004

Naming

How to name classes, packages, methods, …. . Everything needs a name. That’s the problem I’m facing every day and I think every programmer does. There seems to be no book that deals with that issue. Or at least I haven’t found one. So what does the internet hands over.
If you search on java.sun.com you’ll probably find the basic stuff like this: Code Conventions but isn’t there greater help out there?
A really helpful article I found next was on hacknot.info: Naming Classes - Do It Once And Do It Right.
And then I stumbled over a kind of ultimate guide: AmbySoft - Coding Standards For Java.
The articles are obviously good but they aren’t perfect now. I’d really appreciate a good book that only deals with the issues of naming. It shouldn’t define standards and say: “That’s the truth!” but reflect different possibilities and show the advantages as well as the disadvantages of each.
I hope such a book will be available for novice programmers some day.
Maybe I’ll write one myself. :)

Monday, December 8th, 2003

UML

I know the term UML (Unified Modeling Language) covers a very big spectrum. It’s a topic everyone should know at least the basics about.
Well, and because of that I’m presently reading the book ‘The Unified Modeling Language User Guide’ from Grady Booch, James Rumbaugh and Ivar Jacobson. I really recommend you to read this book too if you are interested in Object Oriented Design/Concepts or just want to learn UML.
The possibilites the UML offers to model well designed systems is astronomical. While reading a new dream got born: a programming language which provides clean semantics to realize all these concepts in the real world.
And up to now I’m only on page 200. I wonder what comes next.
In my opinion before we invent a even better way to program then OOP we should try to imporve OOP till it becomes perfect. We shouldn’t always look out for new things. We should improve the old ones.
As you can see at the OOP example it lives since more than 40 years (I’m not really sure about that) and there isn’t a programming language that supports all concepts you could realize via OOP. It should be our task to build such a language. So that in the near futur it isn’t a dream anymore to build a system based on the UML with all the ideas and concepts it offers.