This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Java in General and the fly likes Recomended folder / package / class layout for javadoc Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Recomended folder / package / class layout for javadoc" Watch "Recomended folder / package / class layout for javadoc" New topic
Author

Recomended folder / package / class layout for javadoc

John Vorwald
Ranch Hand

Joined: Sep 26, 2010
Posts: 139
Hi,
I've been writing Java for a while, using eclipse.
Generally, I have a src folder, and put sub folders under src and then put the classes in the sub folders.
So, I don't really use packages, and don't know what packages are used for
Now, when I generate the javadoc, the package/class layout doesn't make sense to me.

How should I layout the folders / packages / classes so that the javadoc organization makes sense.

Generally, I have one target executable for a project. Except that I make a large number of development classes that also execute. The projects have a number of classes that should be organized, possibly into packages, like gui, solver, network, dataobject(s). Also, I make some unit tests and put those classes in test/sub_directory, similar to src/sub_directory. The developmental classes are in development/sub_directory, but the development sub_directory names are associated with the developmental goal, and the sub directory names are different than test and src.

Also, are there any additional files that should be created that would assist javadoc? Like a project description?

John
Joe Areeda
Ranch Hand

Joined: Apr 15, 2011
Posts: 316
    
    2

John,

I do something similar using NetBeans. I am by no means an expert and what I'm offering is a discussion not a recommendation.

I use packages within a project the same way I do a separate class library projects, as an organizational and encapsulation process. Now where to draw the line between a separate package and separate library is kind of fuzzy. It often becomes much more clear during refactoring sessions with the benefit of hind sight in how the classes are used, what they depend on, and the chances of reuse in other projects.

Writing good javadoc is a lot like any good writing. The tricks I've learned are:

  • Read other peoples' javadoc with a critical eye for what you like and what you don't
  • Consider your audience, they are people digging into your code but are they maintaining or reusing?
  • The real hard part is to be informative without including unnecessary details that risk code and documentation conflicts
  • Use the javadoc, and fix it instead of cursing it


  • I've seen too many descriptions that are redundant such as int getDoDah() "return the current value of DoDah", when what I really want to know is what the heck is a DoDah.

    On the other end I've also seen boolean checkValue(int it) "returns true if it is less than 10" and the code looks like "return it<5;"

    NetBeans presents the javadoc while typing and I'm pretty sure Eclipse does too. I use it most to make sure my method parameters are correct. So I try to read it almost every time and if I have to go to the code to answer a question, that's the perfect time to update the javadoc.

    Now generating the whole javadoc for a project and reading it from the perspective of the person you're going to send it to, helps a lot. But I find the details are used much more than the overviews.

    To address your question how to organize your project into packages so the documentation is more understandable, I think it is a design exercise as much as a documentation chore. I do it as an iterative process but I'm very much into the minimal design, rapid prototype development, and endless refinement paradigm. I tend to end up with a prototype with one package then divide it into UI, database, network, non-interactive processing for example. Sometimes that's a lot of work if the prototype is severely criticized. But just as often I get to throw out big chunks of the prototype because I was just plain wrong about what I thought people would do with it. That's easier if there's not a big investment of time and energy in each Class and method.

    After rereading that, it sure is a bunch of general jibber jabber. Hope some of it makes sense.

    Joe


    It's not what your program can do, it's what your users do with the program.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 38511
        
      23
    I am a bit surprised that you don’t have your classes in packages. The javadoc tool does not require any particular package structure that I know about, but you ought to be putting your files in packages. In fact, Eclipse usually complains if you don’t use package names.
    I am not quite sure I have understood your problem, but I presume you have seen the Javadoc style guide, and a link I found on Google about package descriptions.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 38511
        
      23
    You can set a preference in your IDE that public members of classes must have documentation comments, or similar. Then you will get a yellow warning if you forget the comments. You write /**-enter, just before a completed member and you get a skeleton comment.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Recomended folder / package / class layout for javadoc