Contribute to help us improve!
Are there edge cases or problems that we didn't consider? Is there a technical pitfall that we should add? Did we miss a comma in a sentence?
If you have any input for us, we would love to hear from you and appreciate every contribution. Our goal is to learn from projects for projects such that nobody has to reinvent the wheel.
Let's collect our experiences together to make room to explore the novel!
To contribute click on Contribute to this page on the toolbar.
Coding Conventions
devon4node defines some coding conventions in order to improve the readability, reduce the merge conflicts and be able to develop applications in an industrialized way.
In order to ensure that you are following the devon4node coding conventions, you can use the following tools:
-
ESLint
: ESLint ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs. We recommend to use the ESLint VSCode extension (included in the devonfw Platform Extension Pack) in order to be able to see the linting errors while you are developing. -
Prettier
: Prettier is a code formatter. We recommend to use the Prettier VSCode extension (included in the devonfw Platform Extension Pack) and enable theeditor.formatOnSave
option. -
devon4node application schematic
: this tool will generate code following the devon4node coding conventions. Also, when you generate a new project using the devon4node application schematic, it generates the configuration files for TSLint and Prettier that satisfy the devon4node coding conventions.
When you combine all tools, you can be sure that you follow the devon4node coding conventions.
Detailed devon4node Coding Conventions
Here we will detail some of most important devon4node coding conventions. To be sure that you follows all devon4node coding conventions use the tools described before.
Indentation
All devon4node code files must be indented using spaces. The indentation with must be 2 spaces.
White space
In order to improve the readability of your code, you must introduce whitespaces. Example:
if(condition){
must be
if (condition) {
Naming conventions
File naming
The file name must follow the pattern: (name in kebab case).(kind of component).(extension) The test file name must follow the pattern: (name in kebab case).(kind of component).spec.(extension)
Example:
auth-jwt.service.ts
auth-jwt.service.spec.ts
Interface naming
The interface names must be in pascal case, and must start with I. There is some controversy in starting the interface names with an I, but we decided to do it because is most of cases you will have an interface and a class with the same name, so, to differentiate them, we decided to start the interfaces with I. Other devonfw stacks solves it by adding the suffix Impl
in the class implementations.
Example:
interface ICoffee {}
Declarations
For all variable declarations we must use const
or let
. var
is forbidden. We prefer to use const
when possible.
Programming practices
Trailing comma
All statements must end with a trailing comma. Example:
{
one: 'one',
two: 'two' // bad
}
{
one: 'one',
two: 'two', // good
}
Arrow functions
All anonymous functions must be defined with the arrow function notation. In most of cases it’s not a problem, but sometimes, when you do not want to bind this
when you define the function, you can use the other function definition. In this special cases you must disable the linter for those sentence.
Pre-commit hooks
In order to ensure that your new code follows the coding conventions, devon4node uses by default husky. Husky is a tool that allows you to configure git hooks easily in your project. When you make a git commit
in your devon4node project, it will execute two actions:
-
Prettify the staged files
-
Execute the linter in the staged files
If any action fails, you won’t be able to commit your new changes.
If you want to skip the git hooks, you can do a commit passing the --no-verify flag.
|