有哪些编码准则的好例子?我并不是在寻找特定于一种语言的内容。
但是,当我撰写编码准则时应该做些什么或评估些什么呢?例如,准则应该多灵活以及应该将多少决策留给程序员或其他人或甚至由准则预先决定。
我正在制定的这套准则应涵盖广泛的主题:注释、数据库设计,甚至包括一些用户界面规范。
有哪些编码准则的好例子?我并不是在寻找特定于一种语言的内容。
但是,当我撰写编码准则时应该做些什么或评估些什么呢?例如,准则应该多灵活以及应该将多少决策留给程序员或其他人或甚至由准则预先决定。
我正在制定的这套准则应涵盖广泛的主题:注释、数据库设计,甚至包括一些用户界面规范。
编码规范通常有三个目的:
显然,第三个目的浪费了其他人的时间,但你需要考虑它,特别是为了避免走上这条路。
话虽如此,我注意到一些明确的做和不做:
m_member
,那么维护程序员应该使用m_member2
而不是应用任何其他标准(例如member2_
或m_lpcstrMember2
或其他)。本地一致性至关重要。最后,最重要的是要定期进行同行之间的代码审查。鼓励人们在看到“代码异味”时说出来。同时也要让人们意识到建设性的代码批评并不是针对个人的 - 源代码是团队中每个人共享的,而不仅仅属于原始作者。根据我的经验,最严重的问题是设计问题,这些问题无论如何都不能通过任何编码指南来解决。软件设计仍然是一种艺术形式(好或坏),一个人的思维池比一个人的思维更好。
if( !codingGuidelines.Followed)
{
reason = programmer.WhyNot();
if( reason.Acceptable)
{
codingGuidelines.Integrate( reason);
}
else
{
team.GiveAssKicking(programmer);
}
}
这是一个相当开放的问题,答案同样也很开放:
每个指南应该比其带来的收益更省成本。
要小心,因为方程式的每一边都有一些隐藏的部分。
实施成本可能包括排除完全可行的替代方案、扼杀创造力和创新以及鼓励代码审查沦为强调风格上的小错误而非解决真正问题。
收益的价值可能是无形的(因此令人沮丧),对于匆忙的开发者来说可能很烦人,但可能会使你的组织品牌更加强大或更快地将新员工引入项目 - 这可能会抵消遵守规则的小幅增量成本。
我希望有一份编码规范文档来解决团队中的宗教争论。
对于存在多种可行答案且人们倾向于长时间争论的问题,我们希望在整个项目中保持一致,并避免花费过多时间讨论。
好的例子包括“TAB与空格”和“K&R与ANSI大括号放置”。在团队中进行投票,做出决定并将其记录下来。立即将该决定应用于所有现有代码, 并单独检查它。以后不要再讨论此问题。
一般来说,我希望有指南来回答那些通常需要花费很长时间才能回答的问题,而且如果你只是独自编码,这些问题可能会是“个人偏好”。通常它们会指定简洁的事情,比如数据库命名约定和空格与制表符(以及多少个空格),以及注释/文档注释样式。
我认为UI指南与其他指南不同。
我最喜欢的编码风格指南之一是Linux内核编码风格,尽管它没有涉及到我在其他指南中看到的具体细节。
我也喜欢编码风格的想法,它可以帮助开发人员在视觉上识别出不好的/有缺陷的代码。例如,在变量名中包含变量类型可以帮助后来者避免意外地将 int 赋值为 float 等错误。