mirror of
https://github.com/enso-org/enso.git
synced 2024-12-23 13:02:07 +03:00
Update style guides around complexity (#213)
This commit is contained in:
parent
4c779df5af
commit
261660abac
@ -19,6 +19,7 @@ programmer burden; there is usually only _one way_ to lay out code correctly.
|
||||
- [TODO Comments](#todo-comments)
|
||||
- [Other Comment Usage](#other-comment-usage)
|
||||
- [Program Design](#program-design)
|
||||
- [Code Complexity](#code-complexity)
|
||||
- [Testing and Benchmarking](#testing-and-benchmarking)
|
||||
- [Warnings, and Lints](#warnings-and-lints)
|
||||
|
||||
@ -292,6 +293,17 @@ There are, of course, a few other situations where commenting is very useful:
|
||||
Any good style guide goes beyond purely stylistic rules, and also talks about
|
||||
design styles to use in code.
|
||||
|
||||
### Code Complexity
|
||||
While we often have to write complex functionality, we want to ensure that the
|
||||
code itself is kept as simple and easy to read as possible. To do this, please
|
||||
use the following rules:
|
||||
|
||||
- Write single-line expressions wherever possible, rather than writing one
|
||||
complex chunk of code.
|
||||
- Separate intermediate results out to their own variables with appropriate
|
||||
names. Even if they are temporaries, giving them a name is a great aid to code
|
||||
comprehension.
|
||||
|
||||
### Testing and Benchmarking
|
||||
New code should always be accompanied by tests. These can be unit, integration,
|
||||
or some combination of the two, and they should always aim to test the new code
|
||||
|
@ -20,6 +20,7 @@ programmer burden; there is usually only _one way_ to lay out code correctly.
|
||||
- [TODO Comments](#todo-comments)
|
||||
- [Other Comment Usage](#other-comment-usage)
|
||||
- [Program Design](#program-design)
|
||||
- [Code Complexity](#code-complexity)
|
||||
- [Safety](#safety)
|
||||
- [Testing and Benchmarking](#testing-and-benchmarking)
|
||||
- [Warnings, and Lints](#warnings-and-lints)
|
||||
@ -264,6 +265,17 @@ There are, of course, a few other situations where commenting is very useful:
|
||||
Any good style guide goes beyond purely stylistic rules, and also talks about
|
||||
design styles to use in code.
|
||||
|
||||
### Code Complexity
|
||||
While we often have to write complex functionality, we want to ensure that the
|
||||
code itself is kept as simple and easy to read as possible. To do this, please
|
||||
use the following rules:
|
||||
|
||||
- Write single-line expressions wherever possible, rather than writing one
|
||||
complex chunk of code.
|
||||
- Separate intermediate results out to their own variables with appropriate
|
||||
names. Even if they are temporaries, giving them a name is a great aid to code
|
||||
comprehension.
|
||||
|
||||
### Safety
|
||||
Whereas most languages don't have a concept of _safety_, rust comes with a built
|
||||
in notion of `unsafe`. When working with `unsafe` functions and code blocks, you
|
||||
|
@ -20,6 +20,7 @@ programmer burden; there is usually only _one way_ to lay out code correctly.
|
||||
- [TODO Comments](#todo-comments)
|
||||
- [Other Comment Usage](#other-comment-usage)
|
||||
- [Program Design](#program-design)
|
||||
- [Code Complexity](#code-complexity)
|
||||
- [Safety](#safety)
|
||||
- [Testing and Benchmarking](#testing-and-benchmarking)
|
||||
- [Warnings, and Lints](#warnings-and-lints)
|
||||
@ -344,6 +345,17 @@ There are, of course, a few other situations where commenting is very useful:
|
||||
Any good style guide goes beyond purely stylistic rules, and also talks about
|
||||
design styles to use in code.
|
||||
|
||||
### Code Complexity
|
||||
While we often have to write complex functionality, we want to ensure that the
|
||||
code itself is kept as simple and easy to read as possible. To do this, please
|
||||
use the following rules:
|
||||
|
||||
- Write single-line expressions wherever possible, rather than writing one
|
||||
complex chunk of code.
|
||||
- Separate intermediate results out to their own variables with appropriate
|
||||
names. Even if they are temporaries, giving them a name is a great aid to code
|
||||
comprehension.
|
||||
|
||||
### Safety
|
||||
It is incredibly important that we can trust the code that we use, and hence we
|
||||
tend to disallow the definition of unsafe functions in our public API. When
|
||||
|
Loading…
Reference in New Issue
Block a user