Difference between revisions of "Coding conventions"

From PlayOnLinux
Jump to: navigation, search
(Tag: visualeditor)
 
Line 1: Line 1:
 
This page contains some coding convention for PlayOnLinux 5.  
 
This page contains some coding convention for PlayOnLinux 5.  
 +
 +
== Comments ==
 +
* Always keep in mind that the code should speak by itself. If you feel that you need to comment your code so that you can be understood, it probably needs to be redesigned.
 +
* Every public methods and class should be documented according Javadoc syntax
  
 
== Naming convention ==
 
== Naming convention ==
 +
 +
=== Style ===
 
* '''Classes''' name should start with a capital letter. Each words should be separated with a capital letters
 
* '''Classes''' name should start with a capital letter. Each words should be separated with a capital letters
 
* '''Methods''' and '''attributes''' should start with a lower case. Each words should be separated with a capital letters
 
* '''Methods''' and '''attributes''' should start with a lower case. Each words should be separated with a capital letters
 
* '''Variable''' '''types''' should be fully written in capital letters. Each words should be separated with a underscore (_)  
 
* '''Variable''' '''types''' should be fully written in capital letters. Each words should be separated with a underscore (_)  
 +
* '''Package names''' should be written in capital letters
  
 
Example:  
 
Example:  
<pre class='code java'>public abstract class CancelerSynchroneousMessage<RESULT_TYPE> extends SynchroneousMessage implements CancelerMessage {
+
<pre class="code java">public abstract class CancelerSynchroneousMessage<RESULT_TYPE> extends SynchroneousMessage implements CancelerMessage {
 
     private Boolean processCanceled = false;
 
     private Boolean processCanceled = false;
  
Line 24: Line 31:
 
         super.semaphore.release();
 
         super.semaphore.release();
 
     }
 
     }
}
+
}</pre>
</pre>
+
 
 +
=== Content ===
 +
* Always give a clear and comprehensible name representing what you are manipulating.
 +
* Two differents object can't have the same name. Otherwise, they would not be different. Avoid for example
 +
 
 +
File file1 = new File();
 +
 
 +
File file2 = new File();
 +
* Avoid declaring methods starting by "get", "is" or "set". These names are reserved for getters and setters.
 +
* Don't call a class "List", "Array" or "Map" except if the class is really implementing a List or a Map object.
 +
* Start abstract classes with "Abstract"
 +
 
 +
==== Interfaces ====
 +
There are two different kind of interface in the code:
 +
* Common and generic interfaces that are used across all the project. In general, their name ends by "able" (Exemple: Observable, Iterable, ...). For those interface we don't have any convention for the name of the implementation for the moment.
 +
** ''com.playonlinux.utils interfaces belong to these category''
 +
* PlayOnLinux API Interfaces. They are made to separate the contract from the implementation to make the code clearer and more testable.) (For example: SetupWindow, UIMessageSender, Controller, ...)
 +
** ''com.playonlinux.api''
 +
** ''com.playonlinux.ui.api''
 +
For these interface, please use the following convention for the implementation: '''InterfaceName'''''ImplementationType''Implementation
 +
 
 +
Exemple: SetupWindowJavaFXImplementation
 +
 
 +
== Syntax convention ==
 +
* Block statements:
 +
 
 +
== Design ==

Latest revision as of 21:36, 7 May 2015

This page contains some coding convention for PlayOnLinux 5.

Comments

  • Always keep in mind that the code should speak by itself. If you feel that you need to comment your code so that you can be understood, it probably needs to be redesigned.
  • Every public methods and class should be documented according Javadoc syntax

Naming convention

Style

  • Classes name should start with a capital letter. Each words should be separated with a capital letters
  • Methods and attributes should start with a lower case. Each words should be separated with a capital letters
  • Variable types should be fully written in capital letters. Each words should be separated with a underscore (_)
  • Package names should be written in capital letters

Example:

public abstract class CancelerSynchroneousMessage<RESULT_TYPE> extends SynchroneousMessage implements CancelerMessage {
    private Boolean processCanceled = false;

    public RESULT_TYPE getResponse() throws InterruptedException, CancelException {
        RESULT_TYPE response = (RESULT_TYPE) super.getResponse();

        if(this.processCanceled) {
            throw new CancelException();
        }

        return response;
    }

    public void sendCancelSignal() {
        this.processCanceled = true;
        super.semaphore.release();
    }
}

Content

  • Always give a clear and comprehensible name representing what you are manipulating.
  • Two differents object can't have the same name. Otherwise, they would not be different. Avoid for example

File file1 = new File();

File file2 = new File();

  • Avoid declaring methods starting by "get", "is" or "set". These names are reserved for getters and setters.
  • Don't call a class "List", "Array" or "Map" except if the class is really implementing a List or a Map object.
  • Start abstract classes with "Abstract"

Interfaces

There are two different kind of interface in the code:

  • Common and generic interfaces that are used across all the project. In general, their name ends by "able" (Exemple: Observable, Iterable, ...). For those interface we don't have any convention for the name of the implementation for the moment.
    • com.playonlinux.utils interfaces belong to these category
  • PlayOnLinux API Interfaces. They are made to separate the contract from the implementation to make the code clearer and more testable.) (For example: SetupWindow, UIMessageSender, Controller, ...)
    • com.playonlinux.api
    • com.playonlinux.ui.api

For these interface, please use the following convention for the implementation: InterfaceNameImplementationTypeImplementation

Exemple: SetupWindowJavaFXImplementation

Syntax convention

  • Block statements:

Design