没有合适的资源?快使用搜索试试~ 我知道了~
资源详情
资源评论
资源推荐
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.4
1.4.1
1.4.2
1.5
1.5.1
1.6
1.7
1.7.1
1.7.2
1.8
1.8.1
1.8.2
1.9
1.10
1.11
1.12
1.13
TableofContents
0.介绍
1.序言
2.代码命名规范
2.1.代码命名基础
2.2.方法(Method)命名
2.3.函数(Function)命名
2.4.属性(Property)与数据类型命名
2.5.其它命名规范
2.6.可接受缩略名
3.代码格式规范
3.1.代码注释格式
3.2.代码结构与排版
4.开发实践
4.1.Objective-C保留字
5.Xcode工程结构
6.版本控制
6.1.Git基本配置
6.2.Git分支模型
7.附录
7.1.Xcode扩展插件
7.2.第三方开源库
8.参考
9.iOS开发优化
*Swift编码规范
Objective-C新特性
iOS生命周期
1
介绍
该文档主要面向iOS开发团队,以CodingGuidelinesforCocoa为基础针对编码、项目架构、
开发实践等进行规范和约定。持续更新中......
Summary
0.介绍
1.序言
2.代码命名规范
2.1.代码命名基础
2.2.方法(Method)命名
2.3.函数(Function)命名
2.4.属性(Property)与数据类型命名
2.5.其它命名规范
2.6.可接受缩略名
3.代码格式规范
3.1.代码注释格式
3.2.代码结构与排版
4.开发实践
4.1.Objective-C保留字
5.Xcode工程结构
6.版本控制
6.1.Git基本配置
6.2.Git分支模型
7.附录
7.1.Xcode扩展插件
7.2.第三方开源库
8.参考
9.iOS开发优化
*Swift编码规范
Objective-C新特性
0.介绍
2
序言
本篇转载自为什么谷歌要执行严格的代码编写规范。原文:StuffEveryoneShouldDo
(part2):CodingStandards
我们在谷歌所做事情中另外一个让我感到异常有效、有用的制度是严格的编码规范。
在到Google工作之前,我一直认为编码规范没有什么用处。我坚信这些规范都是官僚制度下
产生的浪费大家的编程时间、影响人们开发效率的东西。
我是大错特错了。
在谷歌,我可以查看任何的代码,进入所有谷歌的代码库,我有权查看它们。事实上,这种
权限是很少人能拥有的。但是,让我感到惊讶的却是,如此多的编码规范—缩进,命名,文
件结构,注释风格—这一切让我出乎意料的轻松的阅读任意一段代码,并轻易的看懂它们。
这让我震惊—因为我以为这些规范是微不足道的东西。它们不可能有这么大的作用—但它们
却起到了这么大的作用。当你发现只通过看程序的基本语法结构就能读懂一段代码,这种时
间上的节省不能不让人震撼!
反对编码规范的人很多,下面是一些常见的理由,对于这些理由,我以前是深信不疑。
1.序言
3
这是浪费时间!
我是一个优秀的程序员,我不愿意浪费时间干这些愚蠢的事。我的技术很好,我可以写
出清晰的、易于理解的代码。为什么我要浪费时间遵守这些愚蠢的规范?答案是:统一
是有价值的。就像我前面说的—你看到的任何的一行代码—不论是由你写的,还是由你
身边的同事,还是由一个跟你相差11个时区的距离人写的—它们都有统一的结构,相同
的命名规范—这带来的效果是巨大的。你只需要花这么少的功夫就能看懂一个你不熟悉
(或完全未见过)的程序,因为你一见它们就会觉得面熟。
我是个艺术家!
这种话很滑稽,但它反映了一种常见的抱怨。我们程序员对于自己的编码风格通常怀有
很高的自负。我写出的的代码的确能反映出我的一些特质,它是我思考的一种体现。它
是我的技能和创造力的印证。如果你强迫我遵守什么愚蠢的规范,这是在打压我的创造
力。可问题是,你的风格里的重要的部分,它对你的思想和创造力的体现,并不是藏身
于这些微不足道的句法形式里。(如果是的话,那么,你是一个相当糟糕的程序员。)规范
事实上可以让人们可以更容易的看出你的创造力—因为他们看明白了你的作品,人们对
你的认识不会因不熟悉的编码形式而受到干扰。
所有人都能穿的鞋不会合任何人的脚!
如果你使用的编码规范并不是为你的项目专门设计的,它对你的项目也许并不是最佳方
案。这没事。同样,这只是语法:非最优并不表示是不好。对你的项目来说它不是最理
想的,但并不能表明它不值得遵守。不错,对于你的项目,你并没有从中获得该有的好
处,但对于一个大型公司来说,它带来的好处是巨大的。除此之外,专门针对某个项目
制定编码规范一般效果会更好。一个项目拥有自己的编码风格无可厚非。但是,根据我
的经验,在一个大型公司里,你最好有一个统一的编码规范,特定项目可以扩展自己特
定的项目方言和结构。
我善长制定编码规范!
这应该是最常见的抱怨类型了。它是其它几种反对声音的混合体,但它却有自身态度的
直接表现。有一部分反对者深信,他们是比制定编码规范的人更好的程序员,俯身屈从
这些小学生制定的规范,将会降低代码的质量。对于此,客气点说,就是胡扯。纯属傲
慢自大,荒唐可笑。事实上他们的意思就是,没有人配得上给他们制定规范,对他们的
代码的任何改动都是一种破坏。如果参照任何一种合理的编码规范,你都不能写出合格
的代码,那只能说你是个烂程序员。
当你按照某种编码规范进行编程时,必然会有某些地方让你摇头不爽。肯定会在某些地方你
的编码风格会优于这些规范。但是,这不重要。在某些地方,编码规范也有优于你的编程风
格的时候。但是,这也不重要。只要这规范不是完全的不可理喻,在程序的可理解性上得到
1.序言
4
的好处会大大的补偿你的损失。
但是,如果编码规范真的是完全不可理喻呢?
如果是这样,那就麻烦了:你被糟蹋了。但这并不是因为这荒谬的编码规范。这是因为你在
跟一群蠢货一起工作。想通过把编码规范制定的足够荒谬来阻止一个优秀的程序员写出优秀
的代码,这需要努力。这需要一个执著的、冷静的、进了水的大脑。如果这群蠢货能强行颁
布不可用的编码规范,那他们就能干出其它很多傻事情。如果你为这群蠢货干活,你的确被
糟蹋了—不论你干什么、有没有规范。(我并不是说罕有公司被一群蠢货管理;事实很不幸,
我们这个世界从来就不缺蠢货,而且很多蠢货都拥有自己的公司。)
1.序言
5
剩余100页未读,继续阅读
又可乐
- 粉丝: 60
- 资源: 309
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0