Nim编码风格

介绍

Nim语言不限制开发人员使用哪种具体的编码风格,

但为了社区的发展,在编写一些标准库的时候还是应该遵从统一的编码风格

这篇文章会列出一系列的编码风格准则,供大家参考。

但值得注意的是,有很多例外场景会与这些准则相悖,

而且,nim语言非常灵活,在一些特定上下文中,这些编码风格准则也不适用。

跟python相似,python的编码风格在不断演化、改变,

nim语言也是这样,随着时间的推移,这个编码风格准则也会改变。

在编写nim的基础类库、编译器、官方工具的时候,

强制要求遵从这些编码风格准则

间距和空白约定

  • 一行的代码量不应该超过80个字符,一行代码量太多的话不利于阅读;
  • 应该使用两个空格来制定缩进,不能使用tab按键来制定缩进;这是因为对于不同的编辑器来说,空格所代表的宽度都是一样的,但制表符所代表的宽度可能是不同的;
  • 虽然开发人员可以使用空格来格式化代码,但是需要注意的是,并不是所有的编辑器都能完成自动对齐工作;

下面这段代码是不推荐的案例

# 下面这段代码是不推荐的案例, 
# 如果以后再有人来修改这段代码,
# 他有可能需要重新格式化所有的代码:
type
  WordBool*    = int16
  CalType*     = int
  ... # 5 lines later
  CalId*       = int
  LongLong*    = int64
  LongLongPtr* = ptr LongLong

命名约定

注意:下面我们描述的命名约定有可能过一段时间就会过时了。

应该使用PascalCase(两个单词中每个单词首字母都大写)命名法命名类型标识符

另外,除了一些常量可能会使用PascalCase命名法之外,

其他的标识符都应该使用camelCase(两个单词中,第一个单词的首字母小写,第二个单词的首字母大写)

const aConstant = 42
const FooBar = 4.2 #常量类型约束不是那么明显

var aVariable = "Meep"

type FooBar = object

对于C/C++的包装器来说,nim语言允许开发人员使用ALL_UPPERCASE的命名方式(所有字符都大写),但这看起来实在太丑了。

当命名值、指针、引用类型时,大部分时候的都是直接用一个有意义的名字即可,

也可以根据情况给这些名字加上“Obj”或“Ref”或“Ptr”后缀

对于C/C++的包装器来说,也遵从这样的原则。

type
  Handle = int64 # 常用
  HandleRef = ref Handle # 不那么常用

对于异常或错误类型的变量,需要加上Error尾缀

type UnluckyError = object of Exception

枚举类型的成员应该有一个确定的前缀,一般情况下都是枚举类型名称的缩写

(如果标记为{.pure.}可以不遵从这项约定)

type PathComponent = enum
  pcDir
  pcLinkToDir
  pcFile
  pcLinkToFile

non-pure的枚举值应该使用camelCase命名法

pure枚举值应该使用PascalCase命名法

type PathComponent {.pure.} = enum
  Dir
  LinkToDir
  File
  LinkToFile

对于HTTP  HTML  FTP TCP IP UTF WWW这类词语来说

没必要左右的字母都大写。parseUrl比parseURL要好很多

checkHttpHeader比checkHTTPHeader要好很多

编码约定

只有在流程控制语句需要的时候,才使用return语句

一般情况下都使用默认的result变量

(别忘了nim语言的每个方法中都有一个隐藏的result变量)

一般情况下推荐返回一个[]或者""或者抛出一个异常,而不是返回一个nil

大部分时候用proc(方法)就能满足业务需求了

只有在比较特殊的时候才会用到宏、模版、迭代器、转换器

如果一个变量在其作用域内不会变化,那么尽量用let声明它,(不要用var声明它)

对于用户自定义类型来说,通常建议同时创建"ref"和"object"类型

多行语句和表达式的约定

如果元组类型的定义,长度超过了一行(80个字符),那么就应该分成多行来定义

type
  ShortTuple = tuple[a: int, b: string]
  
  ReallyLongTuple = tuple
    wordyTupleMemberOne: string
    wordyTupleMemberTwo: int
    wordyTupleMemberThree: double

同样,任何类型的声明,如果长度超过一行,应该格式化多行来声明

type
  EventCallback = proc (
    timeRecieved: Time
    errorCode: int
    event: Event
  )

如果一个方法的参数较多,需要在多行内书写,

那么第二行的开始应该与第一行上的左括号对齐

proc lotsOfArguments(argOne: string, argTwo: int, argThree:float
                     argFour: proc(), argFive: bool): int
                    {.heyLookALongPragma.} =

如果你需要调用一个方法,而调用语句很长的话

你可以把每个参数都分做一行,也可以多个参数占用一行(与第一行的左括号对齐)

# 对于复杂方法调用的时候,推荐每个参数占用一行.
readDirectoryChangesW(
  directoryHandle.THandle,
  buffer.start,
  bufferSize.int32,
  watchSubdir.WinBool,
  filterFlags,
  cast[ptr dword](nil),
  cast[Overlapped](ol),
  cast[OverlappedCompletionRoutine](nil)
)

# 简单方法调用时,推荐:多个参数占用一行,与第一行的左括号对齐
startProcess(nimExecutable, currentDirectory, compilerArguments
             environment, processOptions)
时间: 2025-01-15 22:23:23

Nim编码风格的相关文章

JavaScript编码风格

最近在看前端大牛Nicbolas C.Zakas的<编写可维护的JavaScript代码>一书.觉得里面的很多知识点都写的很好,所以,就写篇博文,总结一下吧!编码规范对于程序设计来说是很重要的,因为如果编码风格不一致的话,代码看上去就会很乱,是很难维护的.当然,不同的开发团队有着不同的编码规范,比较著名的有,Google编码规范,jQuery编码规范,dojo编码规范以及Yahoo!编码规范,等等. 第一,Indentation Levels(缩进).目前比较流行的是2空格缩进和4空格缩进,比

一步一步学Python(1) 基本逻辑控制举例和编码风格规范

(1) 基本逻辑控制举例和编码风格规范 1.while死循环 2.for循环 3.if,elif,else分支判断 4.编码风格(官方建议) 版本:Python3.4 1.while死循环 >>> import time >>> i = 0 >>> while 1: ... i += 1 ... print(i) ... time.sleep(3) ... 1 2 3 ^CTraceback (most recent call last): File

verilog HDL 编码风格

1.有意义且有效的名字. 2.同一信号在不同层次应该保持一致. 3.添加有意义的后缀,使信号的有效性更加明确. 4.模块输出寄存器化,使得输出的驱动强度和输入延时是可以预测的. 5.使用括号表明优先级. 6.每一个if都应该有一个else.如果esle没有任何相应的动作,则用一条空语句.(if..esle可能有优先级) 7.case 语句最好有一个default分支,如果default不要执行动作就使用空语句. 8.在每个 模块的开始做模块级的注释,在模块端口列表中出现的信号做简要的功能描述.

PSR-2 编码风格规范

本篇规范是 PSR-1 基本代码规范的继承与扩展. 本规范希望通过制定一系列规范化PHP代码的规则,以减少在浏览不同作者的代码时,因代码风格的不同而造成不便. 当多名程序员在多个项目中合作时,就需要一个共同的编码规范, 而本文中的风格规范源自于多个不同项目代码风格的共同特性, 因此,本规范的价值在于我们都遵循这个编码风格,而不是在于它本身. 关键词 "必须"("MUST")."一定不可/一定不能"("MUST NOT").&q

来自 Google 的 R 语言编码风格指南

本文转自Xiao Nan的博客 R语言是一门主要用于统计计算和绘图的高级编程语言. 这份 R 语言编码风格指南旨在让我们的 R 代码更容易阅读.分享和检查. 以下规则系与 Google 的 R 用户群体协同设计而成. 概要: R编码风格约定 文件命名: 以 .R (大写) 结尾 标识符命名: variable.name, FunctionName, kConstantName 单行长度: 不超过 80 个字符 缩进: 两个空格, 不使用制表符 空白 花括号: 前括号不折行写, 后括号独占一行 赋

python基础之类的编码风格

自定义工作流程: 一开始应让代码结构尽可能简单.先尽可能在一个文件中完成所有的工作,确定一切都能正确运行后,再将类移动独立的模块中.如果你喜欢模块和文件的交互方式,可在项目开始时就尝试将类存储到模块中.先找出让你能够编写出可行代码的方式,再尝试让代码更为组织有序. 类编码风格: 你必须熟悉有些与类相关的编码风格问题,在你编写的程序较复杂时尤其如此. 类名应采用驼峰命名法,即将类名中的每个单词的首字母都大写,而不使用下划线.实例名和模块名都采用小写格式,并在单词之间加上下划线. 对于每个类,都应紧

C编码风格

C编码风格 编码风格也叫编码规范,就是编写代码时代码的形式.就好比书法.太潦草的肯定不好理解内容,别人也不喜欢看.编码风格目的是为了,让人更容易阅读和理解代码.并能防止一些错误.所以编码风格很重要. ? 对比一下两种代码的书写形式 第一种 第二种 ? 第二个比第一个要人看着舒服多,结构也非常的清晰.找错误的时候也很容易找到. ? 好的编码风格,至少要有缩进,同一逻辑层要对齐. 具体的编码规范请百度.选择一种起码让自己看着舒服的风格.

JavaScript 编码风格指南

A.1  缩进 // 4个空格的层级缩进 if (true) { doSomething(); } A.2  行的长度 // 每行限于80个字符,超出则在运算符后换行,缩进2个层级(8个空格) doSomething(argument1, argument2, argument3, argument4, argument5); A.3  原始值 // 字符串使用双引号及长字符串的链接 var name = "Nicholas", longStr = "this is a lo

UnrealEngine4编码风格的思考

第一次拿到UE4源码,扫了一遍.各种宏定义,各种模板,各种类层次.杂乱无章. 后来慢慢明确其规律: UE4的编码风格是在匈牙利命名法的基础下做了改进,使其更适用游戏引擎业务(业务特点:数据可视编辑.脚本化). UE4保留了匈牙利命名法的大驼峰.使Tag含义更易读. UE4里有非常多类型都以F.U.A.T为前缀,成员变量不加m前缀.为什么呢? 站在设计者的角度,想想UE4的引擎设计思路.引擎必定是很庞大复杂,但再复杂的引擎都是从零设计编码出来的. 设计者设计之初定然明确这是一个庞然大物,要想可控.