11位swift号码 swift码一般几位

admin2024-05-30  16

Swift 编码规范

按大概的先后顺序,本文尝试做到以下几点:

  1. 增进精确,减少程序员犯错的可能
  2. 明确意图
  3. 减少冗余
  4. 减少关于美的争论

如果你有什么建议,请看我们的 

pull request. ⚡️


留空白

  • 用 tab,而非 空格
  • 文件结束时留一空行
  • 用足够的空行把代码分割成合理的块
  • 不要在一行结尾留下空白
  • 千万别在空行留下缩进

能用 let 尽量用 let 而不是 var

 尽可能的用 

let foo = ... 而不是 

var foo = ... (并且包括你疑惑的时候)。万不得已的时候,再用 

var (就是说:你 

知道 这个值会改变,比如:有 

weak 修饰的存储变量)。 

理由: 这俩关键字 无论意图还是意义 都很清楚了,但是 

let 可以产生安全清晰的代码。

 

let 保障它的值的永远不会变,对程序猿也是个 

清晰的标记。因此对于它的用法,之后的代码可以做个强而有力的推断。 理解代码也更容易了。不然一旦你用了 

var,还要去推测值会不会变,这时候你就不得不人肉去检查。 相应地,无论何时你看到 

var,就假设它会变,并问自己为啥。

 尽早地 return 或者 break

当你遇到某些操作需要通过条件判断去执行,应当尽早地退出判断条件:你不应该用下面这种写法

if n.isNumber {
	// Use n here
} else {
	return
}

用这个:

guard n.isNumber else {
	return
}
// Use n here

或者你也可以用 

if 声明,但是我们推荐你使用 

guard

理由: 你一但声明 

guard 编译器会强制要求你和 

return

break 或者 

continue 一起搭配使用,否则会产生一个编译时的错误。

避免对 可选类型 强解包

如果你有个 

FooType? 或 

FooType! 的 

foo,尽量不要强行展开它(

foo!)以得到它的关联值。取而代之的,推荐这样:

if let foo = foo {
	// Use unwrapped `foo` value in here
} else {
	// If appropriate, handle the case where the optional is nil
}

或者使用可选链,比如:

// Call the function if `foo` is not nil. If `foo` is nil, ignore we ever tried to make the call
foo?.callSomethingIfFooIsNotNil()


理由: 

if let 绑定可选类型产生了更安全的代码,强行展开很可能导致运行时崩溃。

避免隐式解析的可选类型

如果 foo 可能为 

nil ,尽可能的用 

let foo: FooType? 代替 

let foo: FooType!(注意:一般情况下,

? 可以代替 

!

理由: 明确的可选类型产生了更安全的代码。隐式解析的可选类型也可能会挂。

对于只读属性和 subscript,选用隐式的 getters 方法

如果可以,省略只读属性和 

subscript 的 

get 关键字

所以应该这样写:

var myGreatProperty: Int {
	return 4
}

subscript(index: Int) -> T {
	return objects[index]
}

……而不是:

var myGreatProperty: Int {
	get {
		return 4
	}
}

subscript(index: Int) -> T {
	get {
		return objects[index]
	}
}


理由: 第一个版本的代码意图已经很清楚了,并且用了更少的代码

对于顶级定义,永远明确的列出权限控制

顶级函数,类型和变量,永远应该有着详尽的权限控制说明符

public var whoopsGlobalState: Int
internal struct TheFez {}
private func doTheThings(things: [Thing]) {}

然而在这些函数/类型的内部,可以在合适的地方使用隐式权限控制:

internal struct TheFez {
	var owner: Person = Joshaber()
}


理由: 顶级定义指定为 

internal 很少有恰当的,要明确的确保经过了仔细的判断。在定义的内部重用同样的权限控制说明符就显得重复,而且默认的通常是合理的。

当指定一个类型时,把 冒号和标识符 连在一起

当指定标示符的类型时,冒号要紧跟着标示符,然后空一格再写类型

class SmallBatchSustainableFairtrade: Coffee { ... }

let timeToCoffee: NSTimeInterval = 2

func makeCoffee(type: CoffeeType) -> Coffee { ... }


理由: 类型区分号是对于标示符来说的,所以要跟它连在一起。

此外,指定字典类型时,键类型后紧跟着冒号,接着加一个空格,之后才是值类型。

let capitals: [Country: City] = [sweden: stockholm]


需要时才写上 self

当调用 

self 的属性或方法时,默认隐式引用

self

private class History {
	var events: [Event]

	func rewrite() {
		events = []
	}
}

必要的时候再加上 

self, 比如在(逃逸)闭包里,或者 参数名冲突了:

extension History {
	init(events: [Event]) {
		self.events = events
	}

	var whenVictorious: () -> () {
		return {
			self.rewrite()
		}
	}
}


原因: 在闭包里用 

self 更加凸显它捕获 

self 的语义,别处避免了冗长

首选 struct 而非 class

除非你需要 

class 才能提供的功能(比如 identity 或 

deinitializers),不然就用 

struct要注意到继承通常 

不 是用 类 的好理由,因为 多态 可以通过 协议 实现,重用 可以通过 组合 实现。比如,这个类的分级

class Vehicle {
	let numberOfWheels: Int

	init(numberOfWheels: Int) {
		self.numberOfWheels = numberOfWheels
	}

	func maximumTotalTirePressure(pressurePerWheel: Float) -> Float {
		return pressurePerWheel * Float(numberOfWheels)
	}
}

class Bicycle: Vehicle {
	init() {
		super.init(numberOfWheels: 2)
	}
}

class Car: Vehicle {
	init() {
		super.init(numberOfWheels: 4)
	}
}

可以重构成酱紫:

protocol Vehicle {
	var numberOfWheels: Int { get }
}

func maximumTotalTirePressure(vehicle: Vehicle, pressurePerWheel: Float) -> Float {
	return pressurePerWheel * Float(vehicle.numberOfWheels)
}

struct Bicycle: Vehicle {
	let numberOfWheels = 2
}

struct Car: Vehicle {
	let numberOfWheels = 4
}


理由: 值类型更简单,容易分析,并且 

let 关键字的行为符合预期。

默认 class 为 final

class 应该用 

final 修饰,并且只有在继承的有效需求已被确定时候才能去使用子类。即便在这种情况(前面提到的使用继承的情况)下,根据同样的规则(

class 应该用 

final 修饰的规则),类中的定义(属性和方法等)也要尽可能的用 

final 来修饰

理由: 组合通常比继承更合适,选择使用继承则很可能意味着在做出决定时需要更多的思考。

能不写类型参数的就别写了

当对接收者来说一样时,参数化类型的方法可以省略接收者的类型参数。比如:

struct Composite<T> {
	…
	func compose(other: Composite<T>) -> Composite<T> {
		return Composite<T>(self, other)
	}
}

可以改成这样:

struct Composite<T> {
	…
	func compose(other: Composite) -> Composite {
		return Composite(self, other)
	}
}


理由: 省略多余的类型参数让意图更清晰,并且通过对比,让返回值为不同的类型参数的情况也清楚了很多。

定义操作符 两边留空格

当定义操作符时,两边留空格。不要酱紫:

func <|(lhs: Int, rhs: Int) -> Int
func <|<<A>(lhs: A, rhs: A) -> A

应该写:

func <| (lhs: Int, rhs: Int) -> Int
func <|< <A>(lhs: A, rhs: A) -> A


理由: 操作符 由标点字符组成,当立即连着类型或者参数值,会让代码非常难读。加上空格分开他们就清晰了


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明原文出处。如若内容造成侵权/违法违规/事实不符,请联系SD编程学习网:675289112@qq.com进行投诉反馈,一经查实,立即删除!