ANTS Coding Conventions ------------------------ 1) Maintain the style of the code you are editing. This is the only real rule. 2) "Rules" for new java source code a) Use the style of the other Java source code in the package you're adding the file to. b) Start with a comment that contains the name of the file, the copyright text (with year) and the license. (Just copy a header from an existing file and edit it to taste.) c) Use 4-character indents, tabs are 8 spaces. (Please just avoiding using tabs, though). The emacs-enabled users should use XXX. d) Put opening '{'s on their own line. e) Use standard javadoc documentation conventions. Plus, feel free to add @version and @author lines. @todo is okay (as is 'XXX'). e.2) Use the @throws javadoc everywhere you can. f) For field modifiers use the following order: (public|/*package*/|protected|private) [final] [static] g) When calling methods that throw checked exceptions, please comment them as such. h) Define toString() methods on most objects. They're quite handy. Please include the typename of the object in the string (so callers won't have to). E.g., from ants.core.Capsule.toString() return this.getClass().getName() + "[" + "s=" +NodeAddress.toString(src)+ ";" + "d=" +NodeAddress.toString(dst)+ "]"; i) When trying to decipher a class that someone else wrote you are required to add comments to the class explaining what you had to divine from the code. j) Aggressively mark fields 'final'. If a field should be final but cannot be labeled such because either the compiler isn't smart enough or the code is currently broken, please add an XXX comment to that effect. k) Don't forget to use

between paragraphs in javadoc comments. Feel free to use any HTML markup in a comment (

and
    are probably the only useful ones.) Try not to add hrefs to relative- path files; if you do, update the RELEASE notes to indicate what files might need to be manually included in a documentation update.