NIM Coding Style

Introduced

The Nim language does not restrict which specific coding style the developer uses,

But for the sake of community development, we should follow a unified coding style when writing some standard libraries.

This article will list a series of coding style guidelines for your reference.

But it's worth noting that there are a number of exceptions that are inconsistent with these guidelines,

Moreover, the Nim language is very flexible, and in some specific contexts These coding style guidelines do not apply.

Like Python, Python's coding style is evolving, changing,

The Nim language is the same, and as time goes by, the Code style code will change.

When writing the base class libraries, compilers, and official tools of Nim,

Enforce compliance with these coding style guidelines

Spacing and whitespace conventions

• A line of code should not exceed 80 characters, a line of code too much is not conducive to reading;

• You should use two spaces to make indents, and you cannot use the TAB key to make indents, because the width of the spaces is the same for different editors, but the width of the tabs may be different;

• Although developers can use spaces to format code, it is important to note that not all editors are able to perform automatic alignment work;

The following code is not a recommended case

# The following code is not a recommended case, # If someone later modifies this code, # He may need to reformat all the code: type wordbool* = int16 caltype* = int ... # 5 lines later calid* = int longlong* = Int64 longlongptr* = ptr longlong

Naming conventions

Note: The naming conventions we describe below are likely to be obsolete over time.

The type identifier should be named using Pascalcase (capitalized in the first letter of each word in two words)

In addition, some constants may be used in addition to the Pascalcase naming method,

All other identifiers should use CamelCase (two words, first letter in lowercase, the first letter of the second word capitalized)

Const Aconstant = 42const FooBar = 4.2 #常量类型约束不是那么明显var avariable = "Meep" type FooBar = Object

The NIM language allows developers to use the All_uppercase naming method (all characters are capitalized), but this looks too ugly for C + + wrappers.

When you name a value, a pointer, a reference type, most of the time you use a meaningful name directly,

You can also add "OBJ" or "Ref" or "Ptr" suffixes to these names as appropriate.

This principle is also adhered to in the case of a C + + wrapper.

Type Handle = Int64 # common handleref = ref Handle # less commonly used

For variables of an exception or error type, you need to add an error suffix

Type Unluckyerror = Object of Exception

A member of an enumeration type should have a definite prefix, typically an abbreviation of the enumeration type name

(if marked as {. Pure.} Can not comply with this agreement)

Type pathcomponent = enum Pcdir pclinktodir pcfile pclinktofile

Non-pure enumeration values should use the CamelCase naming method

Pure enumeration values should use the Pascalcase naming method

Type pathcomponent {. pure} = enum Dir linktodir File linktofile

For HTTP HTML FTP TCP IP UTF www such words

There is no need to capitalize the letters. parseURL is a lot better than parseURL.

Checkhttpheader is a lot better than Checkhttpheader.

Coding conventions

Use the return statement only when the Process Control statement is needed

The default result variable is used in the general case

(Don't forget that there is a hidden result variable in each method of the Nim language)

In general, it is recommended to return a [] or "" or throw an exception instead of returning a nil

Most of the time with Proc (method) to meet business needs

macros, templates, iterators, converters are used only when they are more special

If a variable does not change within its scope, try to declare it with let (do not declare it with VAR)

For user-defined types, it is generally recommended to create both "ref" and "Object" types

Conventions for multiline statements and expressions

If the definition of a tuple type is longer than one line (80 characters), then it should be divided into multiple lines to define

Type shorttuple = Tuple[a:int, b:string] reallylongtuple = tuple wordytuplememberone:string Wordytuplemembert Wo:int wordytuplememberthree:double

Similarly, any type of declaration, if it is longer than one line, should be formatted with multiple lines to declare

Type Eventcallback = Proc (timerecieved:time errorcode:int event:event)

If a method has more parameters, it needs to be written in multiple lines,

Then the start of the second line should be aligned with the opening parenthesis on the first line

Proc Lotsofarguments (argone:string, Argtwo:int, Argthree:float Argfour:proc (), argfive:bool): int {. Heylookalongpragma.} =

If you need to call a method and the call statement is long

You can divide each parameter into one row, or you can take a row for multiple arguments (aligned with the opening parenthesis of the first line)

# for complex method calls, it is recommended that each parameter occupy one row. READDIRECTORYCHANGESW (Directoryhandle.thandle, Buffer.start, Buffersize.int32, Watchsubdir.winbool, FilterFlags, cast[ptr DWORD] (NIL), cast[overlapped] (OL), Cast[overlappedcompletionroutine] (nil  ) # Simple method invocation, recommended: Multiple parameters occupy one line, aligned with the opening parenthesis of the first line startprocess (nimexecutable, CurrentDirectory, compilerarguments Environment, Processoptions)

NIM Coding Style