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,
|
Although Nimrod, through its flexible AST and case-sensitivity settings,
|
||||||
supports a variety of code and formatting styles, it is nevertheless beneficial
|
supports a variety of code and formatting styles, it is nevertheless beneficial
|
||||||
that certain community efforts, such as the standard library, should follow
|
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
|
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
|
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
|
as flexible as it is, there will be parts of this style guide that don't make
|
||||||
|
@ -18,9 +18,9 @@ Style Guidelines
|
||||||
|
|
||||||
General
|
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.
|
pascalCase.
|
||||||
```
|
```nimrod
|
||||||
const
|
const
|
||||||
aConstant = 42
|
aConstant = 42
|
||||||
|
|
||||||
|
@ -33,7 +33,7 @@ General
|
||||||
|
|
||||||
- Members of enums should have an identifying prefix, such as an abbreviation
|
- Members of enums should have an identifying prefix, such as an abbreviation
|
||||||
of the enum's name.
|
of the enum's name.
|
||||||
```
|
```nimrod
|
||||||
type PathComponent = enum
|
type PathComponent = enum
|
||||||
pcDir
|
pcDir
|
||||||
pcLinkToDir
|
pcLinkToDir
|
||||||
|
@ -44,7 +44,7 @@ General
|
||||||
- Lines should be no longer than 80 characters
|
- Lines should be no longer than 80 characters
|
||||||
|
|
||||||
- 2 spaces should be used for indentation. Although one can use tabstops for
|
- 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.
|
hack.
|
||||||
|
|
||||||
- The 'return' statement should only be used when it's control-flow properties
|
- 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
|
implicit result variables allows both the Nimrod compiler and its various
|
||||||
backends to perform special optimizations
|
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
|
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
|
variables remain immutable, and gives those who read the code a better idea
|
||||||
of the code's purpose.
|
of the code's purpose.
|
||||||
|
@ -61,7 +61,7 @@ General
|
||||||
regular object type layout instead. This enhances the readability of the
|
regular object type layout instead. This enhances the readability of the
|
||||||
tuple declaration by splitting its members information across multiple
|
tuple declaration by splitting its members information across multiple
|
||||||
lines.
|
lines.
|
||||||
```
|
```nimrod
|
||||||
type
|
type
|
||||||
ShortTuple = tuple[a: int, b: string]
|
ShortTuple = tuple[a: int, b: string]
|
||||||
|
|
||||||
|
@ -73,7 +73,7 @@ General
|
||||||
|
|
||||||
- Similarly, any procedure type declarations that are longer than one line
|
- Similarly, any procedure type declarations that are longer than one line
|
||||||
should be formatted in the style of a regular type.
|
should be formatted in the style of a regular type.
|
||||||
```
|
```nimrod
|
||||||
type
|
type
|
||||||
EventCallback = proc (
|
EventCallback = proc (
|
||||||
timeRecieved: TTime
|
timeRecieved: TTime
|
||||||
|
@ -83,15 +83,42 @@ General
|
||||||
```
|
```
|
||||||
|
|
||||||
- Multi-line procedure declarations/argument lists should continue on the same
|
- Multi-line procedure declarations/argument lists should continue on the same
|
||||||
column as the preceding brace. This style is different from that of procedure
|
column as the opening brace. This style is different from that of procedure
|
||||||
type declarations in order to prevent confusion between the heading of a
|
type declarations in order to distinguish between the heading of a
|
||||||
procedure and its body.
|
procedure and its body.
|
||||||
```
|
```nimrod
|
||||||
proc lotsOfArguments(argOne: string, argTwo: int, argThree:float
|
proc lotsOfArguments(argOne: string, argTwo: int, argThree:float
|
||||||
argFour: proc(), argFive:bool): int
|
argFour: proc(), argFive:bool): int
|
||||||
```
|
```
|
||||||
|
|
||||||
- Use of extra whitespace for alignment is generally discouraged. This is not
|
- Multi-line procedure calls should either have one argument per line
|
||||||
neccessarily because such a style is bad, but because of the varying support
|
(like multi-line type declarations) or continue on the same
|
||||||
editors have for auto aligning blocks of code, and the fact that manually
|
column as the opening parenthesis (like multi-line procedure declarations).
|
||||||
aligning and re-aligning parts of code can be quite time consuming.
|
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