ABCD
1
IDDescriptionLink documentationLink exemple
2
DEVSTD-1Always use English language in source code
3
DEVSTD-2Never use stderr and stdout (Exception.printStackTrace, System.out, System.err...)
4
DEVSTD-3Define Javadoc for all public classes, methods, attributes and constants
5
DEVSTD-4Use common eXo Code formatting rulesLink
6
DEVSTD-5Format only modified code instead of the whole class
7
DEVSTD-6Avoid using of java.lang.String.intern()Link
8
DEVSTD-7String concatenationLink
9
DEVSTD-8Commits inside PRs must have clear descriptionLink
10
DEVSTD-9Add comments to complex algorithms
11
DEVSTD-10Divide complex code and big services to smaller pieces
12
DEVSTD-11Use eXoLogger for logging purpose
13
DEVSTD-12Never use == to compare Objects
14
DEVSTD-13Never swallow exceptions
15
DEVSTD-14Always log the complete exception (avoid using exception.getMessage())
16
DEVSTD-15Add Unit tests. When the issue is about a bug, the test has to fail wihout the fix and must succeeds with the proposed patch
17
DEVSTD-16Use and implement equals and hashcode methods to compare Objects
18
DEVSTD-17Use braces when using for, while, do/while, if / else and switch blocks
19
DEVSTD-18No whitespace changes or formatting changes has to be made in PRs. In fact, the PR can become unreadable with those changes.
20
DEVSTD-19Before requesting a PR, ensure that the build passes and that the branch is up to date with destination branch
21
DEVSTD-20When merging a PR, if it's about a fix or a quick win, the PR should be squached to a single commit and then merged. Else, if it's a Feature, a "Merge" commit should be added to destination branch
22
DEVSTD-21No exception should be swallowed. A log.debug is sometimes sufficient, if the exception is expected
23
DEVSTD-22No commented code should be committed
24
DEVSTD-23When adding new methods in API, please make sure to add a default implementation to ensure that it doesn't break implementations Mocks in Tests for example
25
DEVSTD-24An exception should be either loggued or rethrown, not both
26
DEVSTD-25Avoid adding CSS in Vue components and place it in gatein-resources.xml as portlet skin
27
DEVSTD-26Use "computed" properties as much as possible inside Vue components instead of objects attributes direct accessPR chat
28
DEVSTD-27Make sure that all RDBMS fields accepts emoticons characters and that it's displayed correctly in front-end only if explicitly not acceptable PLF-8424
29
DEVSTD-28Avoid using org.exoplatform.services.security.ConversationState.getCurrent() in Service & Storage layers. In fact, the access to the currently connected user should be done from higher layer such as REST Service / Portlet.
30
DEVSTD-29No use of npm import directive to define external third party libraries. All JS third party libraries has to be defined using GateIN AMD modules definition in gatein-resources.xml. When adding a new module, make sure to communicate about this new dependency and to add it in gatein-portal to let other addons reuse it, if the library is defined in a supported addon.
31
DEVSTD-30Avoid defining colors outside the file variables.less of platform-ui project.
32
DEVSTD-31Avoid defining new colors that wasn't specified in branding chart of eXo Platform by designers
33
DEVSTD-32Data structure upgrades of JPA Entities has to be made using Liquibase changelogs
34
DEVSTD-33Data content upgrades has to be made using Commons-Upgrade API (See link for more details)link
35
DEVSTD-34When naming a Vue file, it has to be an explicit name that references the addon/project, the module/portlet and its name. This naming convension is like naming an FQN of a class. In fact, in eXo Platform, we have multiple Vue instances in a single page, by using this naming convension, we will avoid names collision, same as defining the same FQN of a java class in two jars.linklink
36
DEVSTD-35Each portlet style has to be defined with parent ID style, example: #AwsomePortletId {...other styles...}
This will avoid applying styles on other elements outside the portlet and thus avoid regressions.
37
DEVSTD-36Use @RolesAllowed annontation in ALL REST endpoint METHODs (not classes) in order to restrict access whether to all connected "users" or to "administrators" only (when this is about an administration operation).
Exceptions: in some cases we need to avoid adding @RolesAllowed to allow access to an endpoint, thus a token validation process MUST be made for anonymous users, see org.exoplatform.social.rest.impl.user.UserRestResourcesV1.getUserAvatarById AND org.exoplatform.agenda.rest.AgendaEventRest.sendEventResponse
38
DEVSTD-37Use HTMLSanitizer in REST endpoints when retrieving user data that will be displayed as HTML in Client Side.
As example, Task Description or Activity.
link
39
DEVSTD-38The same form validations made on client-side MUST be made on server-side as well to avoid inconsistency when using endpoints in custom development
40
DEVSTD-39Never use Vue directive v-html on Data provided by user to avoid XSS attacks only when having already sanitized the content, where its content can be considered as safe.
For example, writing an activity using WYSIWYG will produce an HTML that will be stored in Server Side, bu when displaying it, the HTMLSanitizer has to be used in Server-end (or similar tool in Client-side) before displaying activity content to the end user.
link
Note that user-provided HTML can never be considered 100% safe unless it’s in a sandboxed iframe or in a part of the app where only the user who wrote that HTML can ever be exposed to it. Additionally, allowing users to write their own Vue templates brings similar dangers.
41
DEVSTD-40Encode HTTP parameters when displaying it in UI to avoid Non-persistent (reflected) XSS

When displaying in front-end a URL parameter, it should be encoded whether in server side (When it's displayed in JSP/GTMPL) or in client side (When using Javascript/Vue)
- For the server-side, we will have to use StringEscapeUtils.escapeHtml
- For the client side, we will have to use v-text or {{}} to display the information to make sure that it's escaped (Never use v-html here)
linklink
42
DEVSTD-41Use HTTP 404 response code instead of 403 when the URL uses username as path parameter or query parameter. This will avoid to give information about the existance of a User having the requested usernamelink
43
DEVSTD-42Never give the possibility for Server to make HTTP requests to internet (adding a URL as parameter that will be fetched by Server for example or even conscieving a flow in the application that let Server making a flow to internet) => Avoid SSRF attackslink
44
DEVSTD-43Avoid giving access to 'ANY' (anonymous access) to non static and non restricted resources. For example, default JCR nodes MUST grant access to authenticated users (/platform/users) at minimum
45
DEVSTD-44Avoid building manually a link, for example <a href="USER_DATA">, when the data is provided by user.
Instead, you will be able to use 'v-autolinker' to transform a text link into a link element, the sanitization will be made by Autolinker library
linklink
46
DEVSTD-45Implement systematically in Service layer the ACL (permission checks) of all operations coming from REST layer. In other all Service layer calls from REST has to pass current user id and the Service layer has to implement the fine permission check algorithm
47
DEVSTD-46Avoid defining html & gtmpl files in JARs in order to allow customize them in custom extensions
48
DEVSTD-47Separate interfaces from their implementation, put each in a separate jar. This will help define new implementations for available services depending on the defined architecture (Monoloith, Microservice, etc ...)
- All services interfaces, Exceptions should be included in an API module (JAR)
- All implementations and Utils classes sould be put inside Implementations module (JAR)
49
DEVSTD-48Use a clear commit message of format TASK-XYZ (replace XYZ by task number) and a clear description that explains:
1/ What was the previous behavior (Prior ti this change....)
2/ What is changed/impacted by the current change
3/ (Optional) what other alternative solutions/propositions was studied
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100