diff options
author | Jacek Sieka <arnetheduck@gmail.com> | 2024-01-03 14:06:39 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-01-03 14:06:39 +0100 |
commit | c4f98b7696ce74c9952c973b0f09e59234f84917 (patch) | |
tree | 36b8cef8930b15aeb5bfda06708025e9d937328d /doc | |
parent | 20d79c9fb0cd2e72473f5fb08134cf72d0fdd9e7 (diff) | |
download | Nim-c4f98b7696ce74c9952c973b0f09e59234f84917.tar.gz |
Recommend hanging indent in NEP1 (#23105)
This PR modernises the NEP1 style guide to prefer hanging indent over vertial alignment for long code statements while still allowing alignment in legacy code. The change is based on research and study of existing style guides for both braced and indented languages that have seen wide adoption as well as working with a large Nim codebase with several teams touching the same code regularly. The research was done as part of due diligence leading up to [nph](https://github.com/arnetheduck/nph) which uses this style throughout. There are several reasons why hanging indent works well for collaboration, good code practices and modern Nim features: * as NEP1 itself points out, alignment causes unnecessary friction when refactoring, adding/removing items to lists and otherwise improving code style or due to the need for realignment - the new recommendation aligns NEP1 with itself * When collaborating, alignment leads to unnecessary git conflicts and blame changes - with hanging indent, such conflicts are minimised. * Vertical alignment pushes much of the code to the right where often there is little space - when using modern features such as generics where types may be composed of several (descriptively named) components, there is simply no more room for parameters or comments * The space to the left of the alignemnt cannot productively be used for anything (unlike on the right, where comments may be placed) * Double hanging indent maintaines visual separation between parameters / condition and the body that follows. This may seem like a drastic change, but in reality, it is not: * the most popular editor for Nim (vscode) already promotes this style by default (if you press enter after `(`, it will jump to an indent on the next line) * although orthogonal to these changes, tools such as `nph` can be used to reformat existing code should this be desired - when done in a single commit, `git blame` is not lost and neither are exsting PRs (they can simply be reformatted deterministically) - `nph` is also integrated with vscode. * It only affects long lines - ie most code remains unchanged Examples of vertical alignment in the wild, for wildly successful languages and formatters: * [PEP-8](https://peps.python.org/pep-0008/#indentation) * [black](https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#how-black-wraps-lines) * [prettier](https://prettier.io/docs/en/) The above examples are useful mainly to show that hanging-indent _generally_ is no impediment to efficient code reading and on the whole is an uncontroversial choice as befits the standard library.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/nep1.md | 40 |
1 files changed, 25 insertions, 15 deletions
diff --git a/doc/nep1.md b/doc/nep1.md index 0c62e3f9c..3d2a0cef3 100644 --- a/doc/nep1.md +++ b/doc/nep1.md @@ -256,36 +256,46 @@ Coding Conventions Conventions for multi-line statements and expressions ----------------------------------------------------- -- Tuples which are longer than one line should indent their parameters to - align with the parameters above it. +- Tuples which are longer than one line should indent their parameters. ```nim type - LongTupleA = tuple[wordyTupleMemberOne: int, wordyTupleMemberTwo: string, - wordyTupleMemberThree: float] + LongTupleA = tuple[ + wordyTupleMemberOne: int, wordyTupleMemberTwo: string, + wordyTupleMemberThree: float] ``` - Similarly, any procedure and procedure type declarations that are longer - than one line should do the same thing. + than one line should do the same thing. Double indent may be used to + distinguish them from the body that follows - this applies to all constructs + with a body (if, while, etc). ```nim type - EventCallback = proc (timeReceived: Time, errorCode: int, event: Event, - output: var string) - - proc lotsOfArguments(argOne: string, argTwo: int, argThree: float, - argFour: proc(), argFive: bool): int - {.heyLookALongPragma.} = + EventCallback = proc( + timeReceived: Time, errorCode: int, event: Event, + output: var string) + + proc lotsOfArguments( + argOne: string, argTwo: int, argThree: float, + argFour: proc(), argFive: bool, argSix: int + ): GenericType[int, string] {.heyLookALongPragma.} = + discard ``` -- Multi-line procedure calls should continue on the same column as the opening - parenthesis (like multi-line procedure declarations). +- Multi-line procedure calls should continue indented (like multi-line procedure + declarations). ```nim - startProcess(nimExecutable, currentDirectory, compilerArguments - environment, processOptions) + startProcess( + nimExecutable, currentDirectory, compilerArguments + environment, processOptions) ``` +Previous versions of this guide advocated vertical alignment along the opening +brace / parenthesis - both styles are permissible with a preference for the +current style in new code. + Miscellaneous ------------- |