So if we want to make sure that no WYSIWYG editing will mess up the code, we
should embed each page in those @x@ markers, which defeats the purpose of
having WYSIWYG. I think proper diffs are important here, even though I see why
Ivo thinks it's more convenient to be able to edit like this, so I would say +1
on disabling, or at least making non-WYSIWYG the default.
Greetings, Marcel
On 11 Oct 2010, at 12:30 , Bram de Kruijff wrote:
>> I guess so. I like the WYSIWIG though, in general it works fine and you can
>> always switch to plain text. So:
>
> That might be the problem ;) If I put code in a page all is well. But then
> when you edit that same page using WYSIWIG a few days later, without even
> looking at or touching my code, it gets messed up. Not sure when and where
> things go wrong (which is kind of the issue). But the one I referred to
> before is this:
>
> 1) Add '@x@' in wiki markup mode and save
> 2) Edit the page in rich text mode (not touching the @x@ which is shown as an
> input field) and save
> 3) The text is no '(x)' and in wiki markup looks like ' \(x)' :S
>
> Note that this only happens outside a '{code}' block and there may be a
> reason that I am not aware of.. but it is scary :)
>
> Grz
> Bram
>
>
>
> From: amdatu-developers-bounces at amdatu.org
> [mailto:amdatu-developers-bounces at amdatu.org] On Behalf Of Ivo Ladage-van
> Doorn
> Sent: Monday, October 11, 2010 12:16 PM
> To: amdatu-developers at amdatu.org
> Subject: Re: [Amdatu-developers] [amdatu] Amdatu > Java Coding Style Guide
>
> I guess so. I like the WYSIWIG though, in general it works fine and you can
> always switch to plain text. So:
> -1 for disabling
>
>
> From: amdatu-developers-bounces at amdatu.org
> [mailto:amdatu-developers-bounces at amdatu.org] On Behalf Of Marcel Offermans
> Sent: maandag 11 oktober 2010 12:00
> To: amdatu-developers at amdatu.org
> Subject: Re: [Amdatu-developers] [amdatu] Amdatu > Java Coding Style Guide
>
> WTF? I just changed the section about line lengths. Is this the WYSIWYG
> editor messing with the code? Probably. Should we disable it?
>
> On 11 Oct 2010, at 11:53 , <webmaster at amdatu.org> wrote:
>
> Java Coding Style Guide
> Page edited by Marcel Offermans
> Comment: as suggested on the mailing list, added an explicit line length
>
> Changes (19)
> ...
> - package and import statements;
> - class and interface declarations.
>
> h3. Beginning comments
> ...
> A few notes must be made here:
> # Package rules.
> When not using an explicit package statement in your code the code still is
> in a package, the default package. This easily results in name clashes and as
> package naming should be a part of the design, always use an explicit package
> name. For naming rules of packages see [naming
> conventions|#namingconventions].
> # Import statements need to be explicit in order to overcome name clashes.
> They must be grouped by name.
> # Import order.
> First in this section should be the standard Java imports like:
> java.lang.Throwable. Second should be the Java extensions (i.e. javax),
> third, the third party stuff. Finally the project-specific imports should be
> added.
>
> h4. Class, interface, enum and annotation declarations
> ...
>
> || Part of declaration || Notes ||
> | (static) variables | These should be grouped by functionality rather than
> by scope. |
> | documentation | According to comment block as shown above. | | class,
> interface, enum or annotation statement | |
> |(static) variables|These | instance variables | These should be grouped by
> functionality rather than by scope. |
> |instance variables|These should be grouped by functionality rather than by
> scope.|
> | constructors | Start with the default constructor if any. | | methods |
> These methods should also be grouped by functionality rather than by scope or
> accessibility. E.g. a private class method can be in between two public
> instance methods. The goal is to make reading and understanding the code
> easier. When implementing an interface, group the methods that are part of
> the interface. | | inner classes | Are placed at the bottom of the file. |
>
> h4. Annotations
> ...
> h2. Indentation
> Four spaces should be used as unit of indentation. Use spaces or let your
> editor convert tabs to spaces as some editors might show the tabs different
> than they were intended\!Tabs must be set exactly every 4 spaces.
>
>
> h3. Line length
> There is no explicit limit for the length of a line. Make sure that the flow
> of the code is clear and that, when printing the file, it is well formed when
> using a reasonable font.
> The length of a single line of code is limited to 120 characters. Make sure
> that the flow of the code is clear and that, when printing the file, it is
> well formed when using a reasonable font.
>
> h3. Wrapping lines
> ...
> h4. Block comments
> The compiler ignores everything from /\* to \*/. Use this style for internal
> comments and copyright headers.
>
> {code}
> ...
> * This code is Copyright (c) 2009 Apache Software Foundation. All rights
> reserved.
> * You are not allowed to remember or reproduce anything you read below.
> */
> {code}
>
> h4. JavaDoc comments
> This indicates a documentation comment (doc comment, for short). The compiler
> ignores this kind of comment, just like it ignores comments that use /\* and
> \*/. The JavaDoc tool uses doc comments when preparing automatically
> generated documentation (See: JavaDoc keywords and HTML tags). Note that
> JavaDoc only uses this documentation when it occurs at an expected position
> in the file like the class definition or a member declaration.
>
> These comments are used to provide English descriptions of the classes,
> interfaces, enums, annotations, methods and the description of data
> structures and algorithms. These comments should be used at the beginning of
> each class and before each method. The official JavaDoc guidelines (see
> references at the end of this document) should be followed, as they provide a
> good and clear writing style.
> ...
> For class headers, method headers and member variables JavaDoc is used in
> order to generate API documentation. Some HTML-tags that can be used in order
> to make the comment blocks more readable:
> || Tag || Short description || | <p> | New paragraph. | | <br> | Break, a
> carriage return. For separation of two paragraphs, usage of <p> is preferred.
> | | <ul><li></li></ul> | Unordered list of items. Each item should start with
> a <li> tag. Most browsers format this as a bullet list. | | <code></code> |
> Code samples. Use this when refering to class names, method names, parameter
> names, etc. |
>
> {note}There is no need to embed the parameter name in the @param tag in
> <code> tags; this is done by JavaDoc automatically. The same holds for the
> exception name in the @exception or @throws tag. In the clarifying text
> however, use the <code> tags when refering to parameter names etc. The
> example below shows the <code> tag being used for the array parameter in the
> text, but not in its definition.{note}
> ...
> *
> * @param list contains the objects to print
> * @param first index of first element in
> * the <code>list</code> to print
> */
> public void printRange(List<Printable> list, int first) {
> {code}
>
> h1. Java syntax and its layout
> ...
>
> # accessibility
> Start with the accessibility as it makes clear if the method or variable is
> reachable at all.
> # static (if applicable)
> # final (if applicable)
> # return type (methods only) or type (for variables)
> For readability, the type is as close to the name as possible.
>
> This order is also compatible with the order that is used in Java for the
> main() method. This results in following sequence:
> ...
> h3. Initialization
> The initialization of class variables is strictly not necessary because of
> the default initialization that takes place for these kinds of members. For
> some types, e.g. Booleans, this requires detailed knowledge of all the
> default values so it is more clear and explicit to initialize each member.
>
> Variables that are used and declared within methods must always be
> initialized explicitly (the compiler will generate an error when you forget
> this).
> ...
> }
> {code}
>
> h2. Statements
> ...
>
> - The enclosed statements should be indented one more level than the compound
> statement.
> - The opening brace should be at the end of the line that begins the compound
> statement; the closing brace should begin a line and be indented to the
> beginning of the compound statement. - Braces are used around all statements,
> even single statements, when they are part of a control structure, such as a
> if-else or for statement. This makes it easier to add statements without
> accidentally introducing bugs due to forgetting to add braces.
>
> h3. if, if-else, if else-if else statements
> ...
>
> Note that in the example the else if construction is started at a new line so
> the statement can not be overlooked.
>
> h3. switch
> ...
> try {
> statements;
> }
> catch (ExceptionClass e) {
> statements;
> ...
> try {
> statements;
> }
> catch (ExceptionClass e) {
> statements;
> ...
> Naming conventions make programs more understandable by making them easier to
> read. They can also give information about the function of the identifier.
> || Identifier Type || Rules for Naming || Examples ||
> | (inner) classes, interfaces, enums and annotations | Names should be nouns,
> in mixed case with the first letter of each word capitalised. Try to keep
> your names simple and descriptive. Use whole words and avoid acronyms and
> abbreviations.|class Raster;abbreviations. | class TreeFrame;| Raster;
> class TreeFrame; |
> | interfaces | Like class names, but if there is a name clash, the interface
> wins. | Repository |
> |services|Same | services | Same as interfaces, so don't append "Service" as
> you usually do not know if an interface is a service or not.|-| not. | \- |
> |implementation classes|If | implementation classes | If a class implements
> an interface, it should use the name of the interface as part of its name,
> adding something specific for this implementation to it, or Impl if that does
> not make sense. | classFileBasedRepository implements Repository; class
> VersionServlet implements HttpServlet; |
> class VersionServlet implements HttpServlet; |
> | exceptions | Like class names; always ending in "Exception" |
> InputException | | methods | Methods should be verbs in mixed case with the
> first letter lowercase. Within each method name capital letters separate
> words. Property methods or get-set methods are used as follows:\\
> When a method is used to get a value start the method name with 'get'. When a
> method is used to set a value start the method name with 'set'.|run();
> runFast(); setBackground();| 'set'. | run();
> runFast(); \\
> setBackground(); |
> | variables (except for (constant) static final variables and member
> variables) | Allvariables are in mixed case with a lowercase first letter.
> Words are separated by capital letters. | int index; float myWidth;|
> float myWidth; |
> |member variables|The | member variables | The same capitalisation as for
> normal variables prefixed with 'm_'. | int m_index; float m_myWidth;|
> float m_myWidth; |
> | constant (static final) variables, enum names | Names should be all
> uppercase with words separated by underscores ("_"). | public static final
> int BLACK = 99; | | packages | Lowercase only; avoid lengthy package names;
> always start with org.apache.ace. | org.apache.ace.demo.bundle |
>
> h1. References
>
> - Java Code Conventions - Sun Microsystems, Inc.
> [http://java.sun.com/docs/codeconv/]
> - How to Write Doc Comments for JavaDoc - Sun Microsystems, Inc.
> [http://java.sun.com/j2se/javadoc/writingdoccomments/]
> - JavaDoc homepage - Sun Microsystems, Inc.
> [http://java.sun.com/j2se/javadoc/]
> Full Content
> Introduction
> This is a Java coding style guide for the project.
> Summary
> This style guide is intended to help the computer professional produce better
> Java programs. It presents a set of specific guidelines for using the
> features of Java in a disciplined manner. The goal is to develop high
> quality, reliable, reusable, portable software. For a number of reasons, no
> programming language can ensure the achievements of these desirable
> objectives on its own. Programming must be embedded in a disciplined
> development process that addresses a number of topics in a well managed way.
> The use of Java is one of those. It must conform to good programming practice
> based on well established software engineering principles. This style guide
> is intended to bridge the gap between these principles and the actual
> practice of programming in Java.
> Clear, readable, understandable source text eases program evolution,
> adaptation and maintenance. First, such source text is more likely to be
> correct and reliable. Second, effective code adaptation is a prerequisite to
> code reuse, a technique that has the potential for drastic reductions in
> system development costs. Easy adaptation requires thorough understanding of
> the software, and that is facilitated considerably by clarity. Finally, since
> maintenance (really evolution) is a costly process that continues throughout
> the life of a system, clarity plays a major role in keeping maintenance costs
> down. Over the entire life cycle, code has to be read and understood far more
> often than it is written; the investment of effort in writing readable,
> understandable code is thus well worthwhile. Many of the guidelines in this
> style guide are designed to promote clarity of the source text.
> This style guide is intended for those involved in the development of real
> software systems written in Java. Different roles in a software project can
> exploit the style guide in different ways. The programmer can use it as a
> reference on good Java style. It can be used in code reviews as a common
> reference. Finally, lessons learned in real projects can be captured by
> extending the style guide.
> Class layout and comments
> This chapter describes the layout for classes, interfaces, enums and
> annotations. These all share a set of common properties, so they will be
> described together and for readability all called 'classes' here.
> Files and filenames
> Files longer than 2000 lines are cumbersome and should be avoided.
> File names
> The file must be named after the class it represents. As for most cases each
> file contains only one class, this is an easy naming convention. For nested
> or inner classes the name of the main class must be the name of the file. As
> names in Java are case-sensitive, the filename is case-sensitive also.
> File organization
> Each Java source file contains a single class or interface. Of course, this
> excludes inner classes as these must be defined without an (outer) class, and
> thus in the same file.
> Java source files have the following ordering:
> * beginning comments;
> * package and import statements;
> * class and interface declarations.
> Beginning comments
> Beginning comments are used for licensing and copyright information only.
> Here at Apache, we embed the ASL 2.0 headers at the top of every file. Note
> that they are not according to the JavaDoc style (See: How to write doc
> comments for JavaDoc - Sun Microsystems, Inc.).
> Package and import statements
> The first non-comment line of most Java source files is a package statement.
> After an empty line import statements can follow. For example:
> package org.apache.ace.core.ui;
>
> import java.awt.Frame;
> import java.io.InputStream;
> A few notes must be made here:
> 1. Package rules.
> When not using an explicit package statement in your code the code still is
> in a package, the default package. This easily results in name clashes and as
> package naming should be a part of the design, always use an explicit package
> name. For naming rules of packages see naming conventions.
> 2. Import statements need to be explicit in order to overcome name clashes.
> They must be grouped by name.
> 3. Import order.
> First in this section should be the standard Java imports like:
> java.lang.Throwable. Second should be the Java extensions (i.e. javax),
> third, the third party stuff. Finally the project-specific imports should be
> added.
> Class, interface, enum and annotation declarations
> The following comment block is an example for the comment that belongs to the
> declaration of a class, interface, enum or annotation. The JavaDoc syntax
> results in the following block:
> /**
> * Configuration manager. Manages the configuration of an application. Has
> features
> * to import and export whole configurations and notifies components that need
> to
> * receive settings.
> */
> The following table describes the parts of a class, interface, enum or
> annotation declaration, in the order that they should appear.
> Part of declaration
> Notes
> documentation
> According to comment block as shown above.
> class, interface, enum or annotation statement
>
> (static) variables
> These should be grouped by functionality rather than by scope.
> instance variables
> These should be grouped by functionality rather than by scope.
> constructors
> Start with the default constructor if any.
> methods
> These methods should also be grouped by functionality rather than by scope or
> accessibility. E.g. a private class method can be in between two public
> instance methods. The goal is to make reading and understanding the code
> easier. When implementing an interface, group the methods that are part of
> the interface.
> inner classes
> Are placed at the bottom of the file.
> Annotations
> Annotations for classes and methods should be done on the line directly above
> the class or method. They should be indented to the same level. An example:
> @Manageable(description = "Starts the system.")
> public void start() {
> // ...
> }
> Annotations for parameters can be inlined like this:
> public void setValue(@Validation("x > 0 && x < 10", "Should be between 0 and
> 10.") int x) {
> // ...
> }
> Indentation
> Four spaces should be used as unit of indentation. Use spaces or let your
> editor convert tabs to spaces as some editors might show the tabs different
> than they were intended! Tabs must be set exactly every 4 spaces.
> Line length
> The length of a single line of code is limited to 120 characters. Make sure
> that the flow of the code is clear and that, when printing the file, it is
> well formed when using a reasonable font.
> Wrapping lines
> When an expression will not fit on a single line, break it according to these
> general principles:
> * break after a comma;
> * break before an operator;
> * prefer higher level breaks to lower level breaks;
> * indent the new line with a tab;
> * if the above rules lead to confusing code or to code that's squished up
> against the right margin, please use common sense.
> Comment
> Comment styles
> The Java language supports three different kinds of comments:
> 1. single line comments;
> 2. block comments;
> 3. JavaDoc comments.
> Single line comments
> The compiler ignores everything from // to the end of the line. Use this
> style when adding a description or some kind of explanation on the same line
> of code or the line above.
> int a; // acceleration of the car
>
> // all names that should be searched
> String[] names;
> Block comments
> The compiler ignores everything from /* to */. Use this style for internal
> comments and copyright headers.
> /*
> * This code is Copyright (c) 2009 Apache Software Foundation. All rights
> reserved.
> * You are not allowed to remember or reproduce anything you read below.
> */
> JavaDoc comments
> This indicates a documentation comment (doc comment, for short). The compiler
> ignores this kind of comment, just like it ignores comments that use /* and
> */. The JavaDoc tool uses doc comments when preparing automatically generated
> documentation (See: JavaDoc keywords and HTML tags). Note that JavaDoc only
> uses this documentation when it occurs at an expected position in the file
> like the class definition or a member declaration.
> These comments are used to provide English descriptions of the classes,
> interfaces, enums, annotations, methods and the description of data
> structures and algorithms. These comments should be used at the beginning of
> each class and before each method. The official JavaDoc guidelines (see
> references at the end of this document) should be followed, as they provide a
> good and clear writing style.
> A method block comment looks as follows:
> /**
> * Position the splitter location at a specified position.
> * This method can for instance be used when the last position
> * is stored as a preference setting for the user.
> *
> * @param position New position of divider, defined in pixels
> * from the left of the containing window.
> * @exception org.apache.ace.units.si.exceptions.PositionException Whenever
> * an invalid position is passed.
> * @see com.sun.java.swing.JSplitPane
> */
> public void setSplitterLocation(int position) throws PositionException {
> HTML tags
> For class headers, method headers and member variables JavaDoc is used in
> order to generate API documentation. Some HTML-tags that can be used in order
> to make the comment blocks more readable:
> Tag
> Short description
> <p>
> New paragraph.
> <br>
> Break, a carriage return. For separation of two paragraphs, usage of <p> is
> preferred.
> <ul><li></li></ul>
> Unordered list of items. Each item should start with a <li> tag. Most
> browsers format this as a bullet list.
> <code></code>
> Code samples. Use this when refering to class names, method names, parameter
> names, etc.
>
> There is no need to embed the parameter name in the @param tag in <code>
> tags; this is done by JavaDoc automatically. The same holds for the exception
> name in the @exception or @throws tag. In the clarifying text however, use
> the <code> tags when refering to parameter names etc. The example below shows
> the <code> tag being used for the array parameter in the text, but not in its
> definition.
> Example:
>
> /**
> * Prints a range from an object array. The range
> * is specified by the first element to print, and
> * ranges to the last element of the array.
> *
> * @param list contains the objects to print
> * @param first index of first element in
> * the <code>list</code> to print
> */
> public void printRange(List<Printable> list, int first) {
> Java syntax and its layout
> Declarations
> When declaring a variable or method make the accessibility as restrictive as
> possible. When using multiple keywords use the following ordering of keywords:
> 1. accessibility
> Start with the accessibility as it makes clear if the method or variable is
> reachable at all.
> 2. static (if applicable)
> 3. final (if applicable)
> 4. return type (methods only) or type (for variables)
> For readability, the type is as close to the name as possible.
> This order is also compatible with the order that is used in Java for the
> main() method. This results in following sequence:
> // A familiar one:
> public static void main(String[] args) {}
> private static String m_lastCreated = null;
> private static final int RED = 4711;
> Number per line
> One declaration per line is recommended since it encourages commenting and it
> does not lead to confusing code. It also is more clear about the explicit
> initialization of variables as discussed in Initialization.
> Example:
> int level = 0; // level where user enters the system
> int horizontalSize = 0; // horizontal size of current level layer
> is preferred over:
> int level, horizontalSize; // level and size of current level layer
> Placement
> In a method, declare local variables just before they are needed. This
> overcomes the problem of a big list of parameters at the beginning of a
> method and the use of a variable becomes more clearly in the context of the
> code, e.g. its initialization.
> Initialization
> The initialization of class variables is strictly not necessary because of
> the default initialization that takes place for these kinds of members. For
> some types, e.g. Booleans, this requires detailed knowledge of all the
> default values so it is more clear and explicit to initialize each member.
> Variables that are used and declared within methods must always be
> initialized explicitly (the compiler will generate an error when you forget
> this).
> Class and Interface Declarations
> When coding Java classes and interfaces, the following formatting rules
> should be followed:
> * no space between a method and its parameter list;
> * "{" appears at the end of the same line as the declaration;
> * "}" starts a line by itself indented to match its corresponding opening
> statement, except when it is a null statement, in which the case the "}"
> should appear immediately after the "{".
> Example:
> public class DefaultStrategy extends Strategy {
> private int m_attempts = 0;
>
> public DefaultStrategy(int attempts) {
> super();
> m_attempts = attempts;
> }
>
> void execute() {}
> }
> Statements
> Simple statements
> Each line should contain at most one statement.
> Compound statements
> Compound statements are statements that contain lists of statements enclosed
> in braces ("{...}"):
> * The enclosed statements should be indented one more level than the compound
> statement.
> * The opening brace should be at the end of the line that begins the compound
> statement; the closing brace should begin a line and be indented to the
> beginning of the compound statement.
> * Braces are used around all statements, even single statements, when they
> are part of a control structure, such as a if-else or for statement. This
> makes it easier to add statements without accidentally introducing bugs due
> to forgetting to add braces.
> if, if-else, if else-if else statements
> There are a lot of nested possibilities for if-else constructions. All these
> variations can be programmed in very cryptic ways that easily and often will
> lead to buggy code. By being more explicit in the used coding style a lot of
> confusion can be taken away.
>
> When using only one statement in a compound block brackets are optional. It
> is good practice, and therefore required, to always use brackets because
> mistakes can be made easily when adding a second statement and brackets are
> forgotten.
> The following example illustrates the correct use of brackets in a few
> different if-then-else constructions:
> if (condition) {
> statement1;
> statement2;
> }
> else {
> statement3;
> }
>
> if (condition) {
> statement1;
> statement2;
> }
> else if (condition1) {
> statement3;
> statement4;
> }
> else {
> statement5;
> statement6;
> }
> Note that in the example the else if construction is started at a new line so
> the statement can not be overlooked.
> switch
> When using a switch statement use following guidelines:
> * Consider including a default case, unless it would do nothing. The break in
> the default case is redundant, but it prevents a fall-through error if later
> another case is added.
> * The so-called fall-through construction should be avoided. Only when there
> are good reasons to use it, make sure that it is very clear that a
> fall-through is used (comment it).
> The next example shows the sample code that uses the guidelines for a switch
> statement:
> switch (condition) {
> case A:
> statements;
> // falls through here, because...
> case B:
> statements;
> break;
> default:
> statements;
> break;
> }
> try - catch
> A try - catch statement should have the following format:
> try {
> statements;
> }
> catch (ExceptionClass e) {
> statements;
> }
> When using finally to add code that always will be executed this will look
> like:
> try {
> statements;
> }
> catch (ExceptionClass e) {
> statements;
> }
> finally {
> statements;
> }
> Note that the catch and the finally start at a new line in order to be
> compliant to the guidelines for if-then-else statements.
> for loops
> New style for loops are generally preferred over old style ones, unless you
> explicitly need the index, or you have to make the code run on pre-Java 5
> virtual machines.
> Old style, a good example that needs the index anyway:
> // lookup a value in a list, return the index
> List<Element> list;
> for (int i = 0; i < list.size(); i++) {
> if (value.equals(list.get(i)) {
> return index;
> }
> }
> New style, a good example that iterates over a list without any need for an
> index or type casts:
> // iterate over a list, printing all values
> List<Element> list;
> for (Element e : list) {
> System.out.println(" - " + e);
> }
> White Space
> Blank lines
> Blank lines improve readability by setting of sections of code that are
> logically related. One blank line should always be used in the following
> circumstances:
> * between class and interface definitions;
> * between methods;
> * before a block or single line comment;
> * between logical sections inside a method to improve readability.
> Blank spaces
> Blank spaces should be used in the following circumstances:
> * A keyword followed by a parenthesis should be separated by a space.
> * while (index > 5) {
> * // ...
> * }
> Note that blanks should not be used between a method call and its opening
> parenthesis. This helps to distinguish keywords from function calls.
> * Blanks should appear after commas in argument lists.
> * All binary and ternary operators except "." should be separated from their
> operands by spaces. Blanks should never separate unary operators such as
> unary minus, increment("++") and decrement("--") from their operands.
> * a += c + d;
> * a = (a + b) / (c * d);
> * a = (b > c) ? b : c;
> * xCoord--;
> * The expressions in a for statement should be separated by blanks.
> * for (expr1; cond1; expr2) {
> * Casts should be followed by a blank.
> * myInstance.doIt((TreeFrame) frame);
> Naming conventions
> Naming conventions make programs more understandable by making them easier to
> read. They can also give information about the function of the identifier.
> Identifier Type
> Rules for Naming
> Examples
> (inner) classes, interfaces, enums and annotations
> Names should be nouns, in mixed case with the first letter of each word
> capitalised. Try to keep your names simple and descriptive. Use whole words
> and avoid acronyms and abbreviations.
> class Raster;
> class TreeFrame;
> interfaces
> Like class names, but if there is a name clash, the interface wins.
> Repository
> services
> Same as interfaces, so don't append "Service" as you usually do not know if
> an interface is a service or not.
> -
> implementation classes
> If a class implements an interface, it should use the name of the interface
> as part of its name, adding something specific for this implementation to it,
> or Impl if that does not make sense.
> class FileBasedRepository implements Repository;
> class VersionServlet implements HttpServlet;
> exceptions
> Like class names; always ending in "Exception"
> InputException
> methods
> Methods should be verbs in mixed case with the first letter lowercase. Within
> each method name capital letters separate words. Property methods or get-set
> methods are used as follows:
> When a method is used to get a value start the method name with 'get'. When a
> method is used to set a value start the method name with 'set'.
> run();
> runFast();
> setBackground();
> variables (except for (constant) static final variables and member variables)
> All variables are in mixed case with a lowercase first letter. Words are
> separated by capital letters.
> int index;
> float myWidth;
> member variables
> The same capitalisation as for normal variables prefixed with 'm_'.
> int m_index;
> float m_myWidth;
> constant (static final) variables, enum names
> Names should be all uppercase with words separated by underscores ("_").
> public static final int BLACK = 99;
> packages
> Lowercase only; avoid lengthy package names; always start with org.apache.ace.
> org.apache.ace.demo.bundle
> References
> * Java Code Conventions - Sun Microsystems, Inc.
> http://java.sun.com/docs/codeconv/
> * How to Write Doc Comments for JavaDoc - Sun Microsystems, Inc.
> http://java.sun.com/j2se/javadoc/writingdoccomments/
> * JavaDoc homepage - Sun Microsystems, Inc.
> http://java.sun.com/j2se/javadoc/
> Change Notification Preferences
> View Online | View Changes | Add Comment
> _______________________________________________
> Amdatu-developers mailing list
> Amdatu-developers at amdatu.org
> http://lists.amdatu.org/mailman/listinfo/amdatu-developers
>
>
> _______________________________________________
> Amdatu-developers mailing list
> Amdatu-developers at amdatu.org
> http://lists.amdatu.org/mailman/listinfo/amdatu-developers
