免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2268 | 回复: 4

[其他] 编码规范使用情况 [复制链接]

论坛徽章:
84
每日论坛发贴之星
日期:2015-12-29 06:20:00每日论坛发贴之星
日期:2016-01-16 06:20:00每周论坛发贴之星
日期:2016-01-17 22:22:00程序设计版块每日发帖之星
日期:2016-01-20 06:20:00每日论坛发贴之星
日期:2016-01-20 06:20:00程序设计版块每日发帖之星
日期:2016-01-21 06:20:00每日论坛发贴之星
日期:2016-01-21 06:20:00程序设计版块每日发帖之星
日期:2016-01-23 06:20:00程序设计版块每日发帖之星
日期:2016-01-31 06:20:00数据库技术版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-14 06:20:00
发表于 2016-02-19 17:38 |显示全部楼层
本帖最后由 yjh777 于 2016-02-19 18:04 编辑

大家参与的项目有编码规范吗?你喜欢你们的编码规范定义吗?

投票区怎么在文字下面?
单选投票, 共有 8 人参与投票

投票已经结束

37.50% (3)
37.50% (3)
12.50% (1)
12.50% (1)
0.00% (0)
0.00% (0)
0.00% (0)
您所在的用户组没有投票权限

论坛徽章:
84
每日论坛发贴之星
日期:2015-12-29 06:20:00每日论坛发贴之星
日期:2016-01-16 06:20:00每周论坛发贴之星
日期:2016-01-17 22:22:00程序设计版块每日发帖之星
日期:2016-01-20 06:20:00每日论坛发贴之星
日期:2016-01-20 06:20:00程序设计版块每日发帖之星
日期:2016-01-21 06:20:00每日论坛发贴之星
日期:2016-01-21 06:20:00程序设计版块每日发帖之星
日期:2016-01-23 06:20:00程序设计版块每日发帖之星
日期:2016-01-31 06:20:00数据库技术版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-14 06:20:00
发表于 2016-02-19 17:43 |显示全部楼层
我们现在是第三项。

转一篇黑编码规范的文章,很有煽动性;
虽然不赞同完全没有编码规范,但是里面的一些话还是有道理,单纯有规范不足以产生好的代码。

以下为转载内容:
-------------------------------------------------------------------------------------------------------------------------------
编码规范是技术上的遮羞布
http://www.aqee.net/why-i-have-given-up-on-coding-standards/
http://www.hksilicon.com/kb/articles/187511

每个程序员都知道,在一个软件公司里,你需要有一套严谨的编码规范。每个程序员也都知道,为了能按自己的编程习惯制订这套规范,每个程序员都在而抗争。刚进入一个新公司时,每个程序员都会内心里绝望,对那套由某些强势架构师独断指定的编码规范恐惧不已。

扔掉编码规范吧,让程序员自由发挥,你会得到更多的好处。从加强代码统一性上获得的这点胜利根本解决不了问题。编码规范就是技术上的遮羞布。在 nearForm 公司,我从来没有想过要制定一个这样的规范,因为我希望每个人都只需按照自己喜欢的方式编程。

这世界太吵闹了。JavaScript的复兴要为此负全责。尤其有一个“特征”:可有可无的分号。无数的主张,猜想和反对声铺天盖地。停止,去实际写些代码好吗。你知道我在说谁。

本意是好的,各路程序员大仙发布各种JavaScript编码规范和风格指导。你们全错了。请停止这种要去拯救这个世界的行为。

编码规范从何来?过程是这样的:在你开始编码时,你跟本不知道会做出什么。这充满乐趣,这是一场游戏,直到你弄瞎一只眼睛。一旦你被自己垃圾的代码伤了太多次,你开始知道你是个菜鸟。于是你开始走上了通往编程大师的道路,你贪婪的咀嚼《代码大全》, 《程序员修炼之道》,当然,还有 Joel。

之 后,事情开始发生了。在通往朝圣的路上,你参透了真经。满腹的技艺让你成为了编程巨星。你的开发效率整整翻了一倍。现在,你要向世界传播。让你有今天成就 的知识也同样能拯救他人。你笼络人心,你传道,你纠缠不休。你训导你的老板要采用最好的实践方法和开发规范。而最不可饶恕的,你竟然开始写博客了。

大多数程序员从来不发声。那些喜欢弄出声响的,都晋升了。你晋升了。你把你绝顶聪明的想法强加给他人。你编写了一套编码规范,你让它成为了法律。

可之后,一切如旧。同样苦干,同样最后期限迫在眉睫,同样bug无数,同样悲惨结局。银弹跟本不存在。

几年后,你不再编码,你成为了管理者。你仍然认定编码规范,条律,制度的至关重要。关键就在于正确的实施。你从来都没有真正的做到过,但你坚持要实现这个目标。不仅如此,你变本加厉。代码量化标准!作为一个管理者,你成了痛苦的化身。

也许事情可能会向另外一个方向发展。也许你重新回去编程,或从未离去。经过一段时间,你发现自己如此无知,所有你的梦想都建立在沙滩上。你放弃了,你放弃了给程序员制订枷锁。这是另一层次的参悟。

至此,你认识到,人不是机器。人需要把智慧发挥到极致。你应该丢掉枷锁,获取最大创造。

可为什么那些最聪明的程序员的做法却完全的相反?为什么他们喜欢控制其它程序员?是什么让他们如此独裁?

首先,你想把你的经验传授给他人。但并非每个人的思维都跟你一样。人的大脑是十分怪异的。

第二,控制别人的感觉良好。但这不可能真正有效的。你不能命令程序员去做什么。猫不是圈养出来的。

第三,你逃避责任。团队中的所有人都这样。我们遵守了规范!项目失败了。没错,可是我们是遵守了规范!

第四,好的意愿;最佳实践;很专业;很技术——诱人的开发过程。你仍在追逐你8岁时想摘到的那颗星星。但是,编程大师如何判断一件事的成败?看结果,这是唯一的标准。

第五,理想主义,你认为你理解整个世界,整个世界要尊崇你的意志。我们人类有些事情非常的在行….但那是在一万次的失败之后,一万次重复的失败。软件工程就是其中之一,不是有了规范就万事大吉的。

而最糟糕的不是这些。万恶之首是,只要你具有上面的任何一点,你最终就会制定出一套编码规范。

编码规范真正的罪恶在于,它们在伤你的心,伤整个团队的心。它们是一种耳语在说你不够优秀。他们不信任你。没有监管,你会搞的一团糟。

一年前我们开创 nearForm 公司,我们最在意的一件事就是要为客户写出最优秀的程序。在早先,我们尝试过所有的开发过程、方法、制度规范。所有都让人讨厌。没有一样真正起到作用。

于是我们开始实施这样的原则:相信我们的程序员是最有智慧的。这起作用了。

我希望所有人都能写出整洁优秀的代码。你自己判断这指的是什么。如果在代码脏乱、变量名不一致的情况下你还能安稳的睡大觉,这你自己决定。但你知道,也许这只是一个100行的用node.js写微型server,无关紧要。这你自己决定。

这是你的责任,因为你一名程序员。

[英文原文:Why I Have Given Up on Coding Standards ]

论坛徽章:
84
每日论坛发贴之星
日期:2015-12-29 06:20:00每日论坛发贴之星
日期:2016-01-16 06:20:00每周论坛发贴之星
日期:2016-01-17 22:22:00程序设计版块每日发帖之星
日期:2016-01-20 06:20:00每日论坛发贴之星
日期:2016-01-20 06:20:00程序设计版块每日发帖之星
日期:2016-01-21 06:20:00每日论坛发贴之星
日期:2016-01-21 06:20:00程序设计版块每日发帖之星
日期:2016-01-23 06:20:00程序设计版块每日发帖之星
日期:2016-01-31 06:20:00数据库技术版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-14 06:20:00
发表于 2016-03-01 15:28 |显示全部楼层
第0条 不要拘泥于小节 (又名:了解哪些东西不应该标准化)

如果人们按照程序员编程的方式修建房屋,那么一只啄木鸟就能毁灭整个文明。
                                                                                                                    --Gerald Weinberg

为了遵从C和C++的伟大传统,我们从0开始编号。首要的指导原则,也就是第0条,阐明了我们认为对编程规范而言最为基本的建议。

接下来,这个导论性部分的其他条款将主要讲述几个精心选择的基本问题,这些问题大多数与代码本身并没有直接关系,它们讨论的是编写坚实代码所必需的工具和技术。

本部分中我们选出的最有价值条款是第0条:"不要拘泥于小节"(又名:"了解哪些东西不应该标准化")。

第0条 不要拘泥于小节 (又名:了解哪些东西不应该标准化)

摘要

只规定需要规定的事情:不要强制施加个人喜好或者过时的做法。

讨论

有些问题只是个人喜好,并不影响程序的正确性或者可读性,所以这些问题不应该出现在编程规范中。任何专业程序员都可以很容易地阅读和编写与其习惯的格式略有不同的代码。

应该在每个源文件乃至每个项目中都使用一致的格式,因为同一段代码中要在几种编程风格(style)之间换来换去是很不舒服的。但是无需在多个项目或者整个公司范围内强制实施一致的格式。

下面列举了几种常见的情况,在这里重要的不是设定规则,而是与所维护的文件中已经使用的体例保持一致。

不要规定缩进多少,应该规定要用缩进来体现代码的结构。缩进空格的数量可以遵照个人习惯,但是至少在每个文件中应该保持一致。

不要强制行的具体长度,应该保证代码行的长度有利于阅读。可以遵照个人习惯来决定行长,但是不要过长。研究表明,文字长度不超过10个单词最利于阅读。

不要在命名方面规定过多,应该规定的是使用一致的命名规范。只有两点是必需的:(1)永远不要使用"晦涩的名称",即以下划线开始或者包含双下划线的名称;(2)总是使用形如ONLY_UPPERCASE_NAMES的全大写字母表示宏,不要考虑使用常见的词或者缩略语作为宏的名称(包括常见的模板参数,比如T和U;像#define T anything这样的代码是极容易混淆的)。此外,应该使用一致的、有意义的名称,遵循文件的或者模块的规范。(如果你无法决定自己的命名规范,可以尝试如下命名规则:类、函数和枚举的名称形如LikeThis,即单词首字母大写;变量名形如likeThis,即第一个单词首字母小写,第二个单词首字母大写;私有成员变量名形如likeThis_;宏名称形如LIKE_THIS。)

不要规定注释风格(除非需要使用工具从特定的体例中提取出文档),应该编写有用的注释。尽可能编写代码而不是写注释(比如,见第16条)。不要在注释中重复写代码语义,这样很容易产生不一致。应该编写的是解释方法和原理的说明性注释。

最后,不要尝试强制实施过时的规则(见例3和例4),即使它们曾经在一些比较陈旧的编程规范中出现过。

示例

例1  大括号的位置。以下代码在可读性方面并不存在区别:

    void using_k_and_r_style() {  
      //……  
    }  
     
    void putting_each_brace_on_its_own_line()  
    {  
      //……  
    }  
     
    void or_putting_each_brace_on_its_own_line_indented()  
      {  
      //……  
      }

任何一个专业程序员都能够毫无困难地阅读和编写这些体例中的任何一种。但是应该保持一致:不要随意地或者以容易混淆作用域嵌套关系的方式放置大括号,要尽量遵循每个文件中已经使用的体例。在本书中,对大括号位置的选择主要是为了能够在编辑允许范围内得到最佳可读性。

例2 空格与制表符。有些团队禁用制表符(比如[BoostLRG]),因为不同的编辑器中制表符的设定是不同的,如果使用不当,会将缩进变为"缩出"和"无缩进"。其他同样受人尊敬的团队则允许使用制表符,并采取了一些能够避免其潜在缺陷的规定。这都是合理的,其实只要保持一致即可:如果允许使用制表符,那么要确保团队成员维护彼此的代码时,不会影响代码的清晰和可读性(见第6条)。如果不允许使用制表符,应该允许编辑器在读入源文件时将空格转换为制表符,使用户能够在编辑器中使用制表符,但是在将文件写回时,一定要将制表符转换回空格。

例3 匈牙利记法。将类型信息并入变量名的记法,是混用了类型不安全语言(特别是C)中的设施,这在面向对象语言中是可以存在的,但是有害无益,在泛型编程中则根本不可行。所以,任何C++编程规范都不应该要求使用匈牙利记法,而在规范中选择禁用该法则是合理的。

例4 单入口,单出口(SESE,Single Entry, Single Exit)。历史上,有些编程规范曾经要求每个函数都只能有一个出口,也就意味着只能有一个return语句。这种要求对于支持异常和析构函数的语言而言已经过时了,在这样的语言中,函数通常都有多个隐含的出口。取而代之,应该遵循类似于第5条那样的标准,即直接提倡更简单的、更短小的函数,这样的函数本身更易于理解,更容易防错。

论坛徽章:
0
发表于 2016-03-10 10:13 |显示全部楼层
也许基本的规范还是要有的,当你拿到一个项目只有一个.c,一个文件好几万行,全篇到处都是全局变量,变量定义是好几种风格,此刻的内心是奔溃的。这样的项目压根没办法接手,后期维护全部是坑,这是我个人经历,深有体会

论坛徽章:
84
每日论坛发贴之星
日期:2015-12-29 06:20:00每日论坛发贴之星
日期:2016-01-16 06:20:00每周论坛发贴之星
日期:2016-01-17 22:22:00程序设计版块每日发帖之星
日期:2016-01-20 06:20:00每日论坛发贴之星
日期:2016-01-20 06:20:00程序设计版块每日发帖之星
日期:2016-01-21 06:20:00每日论坛发贴之星
日期:2016-01-21 06:20:00程序设计版块每日发帖之星
日期:2016-01-23 06:20:00程序设计版块每日发帖之星
日期:2016-01-31 06:20:00数据库技术版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-16 06:20:00程序设计版块每日发帖之星
日期:2016-01-14 06:20:00
发表于 2016-03-10 10:42 |显示全部楼层
回复 4# 2353852917

是的
   
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。




----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP