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 /tests/destructor/tgotoexceptions7.nim | |
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 'tests/destructor/tgotoexceptions7.nim')
0 files changed, 0 insertions, 0 deletions