Added multi-line procedure call styling
This commit is contained in:
parent
7b1b047501
commit
ae3f24df55
57
NEP-1.md
57
NEP-1.md
|
@ -5,7 +5,7 @@ Abstract
|
|||
Although Nimrod, through its flexible AST and case-sensitivity settings,
|
||||
supports a variety of code and formatting styles, it is nevertheless beneficial
|
||||
that certain community efforts, such as the standard library, should follow
|
||||
a consistant set of style guidelines when suitable. This enhancement
|
||||
a consistent set of style guidelines when suitable. This enhancement
|
||||
proposal aims to list a series of guidelines that the standard library should
|
||||
follow. Note that these are *guidelines* only. The nature of Nimrod being
|
||||
as flexible as it is, there will be parts of this style guide that don't make
|
||||
|
@ -18,9 +18,9 @@ Style Guidelines
|
|||
|
||||
General
|
||||
-------
|
||||
- Type identifiers should be in CamelCase. All identifiers should be in
|
||||
- Type identifiers should be in CamelCase. All other identifiers should be in
|
||||
pascalCase.
|
||||
```
|
||||
```nimrod
|
||||
const
|
||||
aConstant = 42
|
||||
|
||||
|
@ -33,7 +33,7 @@ General
|
|||
|
||||
- Members of enums should have an identifying prefix, such as an abbreviation
|
||||
of the enum's name.
|
||||
```
|
||||
```nimrod
|
||||
type PathComponent = enum
|
||||
pcDir
|
||||
pcLinkToDir
|
||||
|
@ -44,7 +44,7 @@ General
|
|||
- Lines should be no longer than 80 characters
|
||||
|
||||
- 2 spaces should be used for indentation. Although one can use tabstops for
|
||||
indentation through use of template filters, this considered an unneccessary
|
||||
indentation through use of template filters, this considered an unnecessary
|
||||
hack.
|
||||
|
||||
- The 'return' statement should only be used when it's control-flow properties
|
||||
|
@ -52,7 +52,7 @@ General
|
|||
implicit result variables allows both the Nimrod compiler and its various
|
||||
backends to perform special optimizations
|
||||
|
||||
- Use the 'let' statement (not the var statement) when declarding variables
|
||||
- Use the 'let' statement (not the var statement) when declaring variables
|
||||
that do not change within their scope. Using the let statement ensures that
|
||||
variables remain immutable, and gives those who read the code a better idea
|
||||
of the code's purpose.
|
||||
|
@ -61,7 +61,7 @@ General
|
|||
regular object type layout instead. This enhances the readability of the
|
||||
tuple declaration by splitting its members information across multiple
|
||||
lines.
|
||||
```
|
||||
```nimrod
|
||||
type
|
||||
ShortTuple = tuple[a: int, b: string]
|
||||
|
||||
|
@ -73,7 +73,7 @@ General
|
|||
|
||||
- Similarly, any procedure type declarations that are longer than one line
|
||||
should be formatted in the style of a regular type.
|
||||
```
|
||||
```nimrod
|
||||
type
|
||||
EventCallback = proc (
|
||||
timeRecieved: TTime
|
||||
|
@ -83,15 +83,42 @@ General
|
|||
```
|
||||
|
||||
- Multi-line procedure declarations/argument lists should continue on the same
|
||||
column as the preceding brace. This style is different from that of procedure
|
||||
type declarations in order to prevent confusion between the heading of a
|
||||
column as the opening brace. This style is different from that of procedure
|
||||
type declarations in order to distinguish between the heading of a
|
||||
procedure and its body.
|
||||
```
|
||||
```nimrod
|
||||
proc lotsOfArguments(argOne: string, argTwo: int, argThree:float
|
||||
argFour: proc(), argFive:bool): int
|
||||
```
|
||||
|
||||
- Use of extra whitespace for alignment is generally discouraged. This is not
|
||||
neccessarily because such a style is bad, but because of the varying support
|
||||
editors have for auto aligning blocks of code, and the fact that manually
|
||||
aligning and re-aligning parts of code can be quite time consuming.
|
||||
- Multi-line procedure calls should either have one argument per line
|
||||
(like multi-line type declarations) or continue on the same
|
||||
column as the opening parenthesis (like multi-line procedure declarations).
|
||||
It is suggested that the former style be used for procedure calls with
|
||||
complex argument structures, and the latter style for procedure calls with
|
||||
simpler argument structures.
|
||||
```nimrod
|
||||
# Each argument on a new line, like type declarations
|
||||
# Best suited for 'complex' procedure calls.
|
||||
readDirectoryChangesW(
|
||||
directoryHandle.THandle,
|
||||
buffer.start,
|
||||
bufferSize.int32,
|
||||
watchSubdir.WinBool,
|
||||
filterFlags,
|
||||
cast[ptr dword](nil),
|
||||
cast[POverlapped](ol),
|
||||
cast[LPOverlappedCompletionRoutine](nil)
|
||||
)
|
||||
|
||||
|
||||
# Multiple arguments on new lines, aligned to the opening parenthesis
|
||||
# Best suited for 'simple' procedure calls
|
||||
startProcess(nimrodExecutable, currentDirectory, compilerArguments
|
||||
environment, processOptions)
|
||||
```
|
||||
|
||||
- Use of extra whitespace for alignment is discouraged. This is not
|
||||
necessarily because such a alignment is bad, but because of the varying
|
||||
support editors have for auto-alignment of text, and the fact that manual
|
||||
alignment and re-alignment can be quite time consuming.
|
Loading…
Reference in New Issue