Questions tagged «coding-standards»

编码标准或编码约定是旨在管理软件项目中代码生成过程的规则或准则集。它们通常基于行业最佳实践或公认的惯例。它们包括命名约定,样式,禁止的功能等。

16
否则块会增加代码复杂度吗?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 这是一个非常简化的示例。这不一定是特定于语言的问题,我想请您忽略函数编写的许多其他方式以及可以对其进行的更改。。颜色是一种独特的类型 string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } else { return "No you can't"; } } 我遇到的很多人,ReSharper和这个人(其评论提醒我我一直想问这个问题已经有一段时间了)建议重构代码以删除else留下的代码块: (我不记得大多数人所说的话,否则我可能不会问这个) string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } return "No you can't"; } 问题:不包括else块会导致复杂性增加吗? else通过说明两个模块中的代码直接相关的事实,我给人的印象更直接地表明了意图。 另外,我发现我可以防止逻辑上的细微错误,尤其是在以后对代码进行修改之后。 以我的简化示例的这种变化形式为例(or由于这是故意简化的示例,因此请忽略运算符): bool CanLeaveWithoutUmbrella() { if(sky.Color != Color.Blue) { …

3
“状态”还是“状态”?变量名称何时应包含单词“状态”,变量名称应何时包含单词“状态”?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 在阅读代码和有关代码的讨论时,我经常看到“状态”和“状态”这两个词可以互换使用,但是似乎存在以下趋势: 当变量具有旨在指示某物处于某种状态的值时,该变量的名称通常不包含单词“状态”或其缩写。 但是,当函数的返回值用于指示某种状态时,我们倾向于将该值称为“状态码”;当该值存储在变量中时,该变量通常称为“状态”或类似名称。 我想孤立地很好,但是当上述变量实际上是相同的时,就需要做出选择,涉及英语(或一般人类语言)的错综复杂。 当要在两者之间进行歧义消除时,目前流行的编码标准或约定是什么?还是应该始终避免这两者之一? 我想,这个english.stackexchange问​​题也很重要。


9
如何在没有技术专长的情况下领导开发项目
我在整个职业生涯中都是动手开发人员,并且喜欢使用代码。我一直对团队负责人感到不满,他们对某项技术几乎没有专门知识,却坚持要求一定的实施。 现在我发现自己在镜架的另一侧。我是使用C#实现的胖客户端的主要开发人员,但是我的专长是构建Java Web应用程序。虽然我知道我可以使用任何一种语言来利用设计模式和OO范式,但是在编码标准,项目生命周期工具和发布/分发过程方面我迷失了。我毫不怀疑我可以在一两个月内掌握基础知识,但是有一些经验只能随着时间的推移而积累。 我应该怎么做,如何避免成为我在开发时讨厌的项目负责人?

13
#define的适当使用是否可以简化重复代码的键入?
对于使用#define定义完整的代码行来简化编码是否有好的看法还是有什么看法?例如,如果我需要一起打印一堆单词,我会很讨厌打字 << " " << 在cout语句中的单词之间插入空格。我可以做 #define pSpace << " " << 和类型 cout << word1 pSpace word2 << endl; 对我来说,这既不会增加代码的清晰度,也不会减少代码的清晰度,并且使键入变得更加容易。在其他情况下,我可以想到在哪里键入通常会更容易进行调试。 有什么想法吗? 编辑:感谢所有的伟大的答案!在进行了很多重复的键入后,这个问题才出现在我的头上,但是我从没想过会使用其他的,不那么混乱的宏。对于不想阅读所有答案的人,最好的选择是使用IDE的宏来减少重复的键入。

8
在使用修订控制的商店中,“由...编辑”内联注释是否是规范?
我们商店的资深开发人员坚持认为,每当修改代码时,负责的程序员都应添加内联注释,说明他的所作所为。这些评论通常看起来像// YYYY-MM-DD <User ID> Added this IF block per bug 1234. 我们使用TFS进行版本控制,在我看来,这种注释更适合作为签入注释而不是内联噪音。TFS甚至允许您将签入与一个或多个错误关联。我们一些较旧的,经常修改的类文件看起来好像它们的LOC比率接近1:1。在我看来,这些注释使代码更难阅读并添加零值。 这是其他商店的标准做法(或至少是常见做法)吗?

10
在编码标准方面与项目负责人存在分歧[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引文回答。 3年前关闭。 因此,我与过去1年的项目负责人一起致力于一个新项目。 最初,我们有自己的子项目,这些子项目位于单独的git repos中,我与他的代码几乎没有交互,因此代码的气味不会打扰我。大约6个月后,由于我在该项目中发挥了更大的作用,因此我开始维护他的代码并向其中添加功能。 现在,我是两个子项目的首席开发人员(团队正在成长;他仍然在我之上),这些事情困扰着我,我想照顾他们,但被拒绝了: 没有花括号,大写函数,混合引号用法(带有隐藏逻辑的双引号和单引号),不使用===,具有巨大功能的巨大类。底线可能更好。 依靠PHP的选项来关闭通知/警告。代码中充满了未经检查的变量和数组键用法。变量在ifs内部定义。 以上两个问题的论点: 不想对人强制执行编码风格。 被视为一种语言功能,可以使代码更短/更有效。 我认为需要制定一些规则,并且代码应具有防御性。我提供了使用PHPStorm的默认设置进行格式设置,使用花括号和社区认可的命名约定的功能。 我想使两个项目使用相同的准则,因为它们是密不可分的。 我错了吗?我会强加我的个人喜好吗?

5
当某些技术是“标准”时,这意味着什么?
我开始学习Java EE 7,经常遇到“标准”一词,但我不明白它的含义。 因此,例如,这是这本书的引文: 与依赖于W3C标准的SOAP和WS- *堆栈相反,REST没有标准,只是一种具有设计原则的体系结构样式。REST应用程序严重依赖于许多其他标准:HTTP,URI,URL ... 我对这可能意味着什么有所了解,但不确定。 我遇到的最好的解释是这里的定义。

6
在调用方中验证输入参数:代码重复?
验证函数输入参数的最佳位置在哪里:在调用方中还是在函数本身中? 因为我想改善自己的编码风格,所以我尝试找到此问题的最佳实践或一些规则。何时何地更好。 在我以前的项目中,我们曾经检查并处理函数中的每个输入参数(例如,如果它不为null)。现在,我在这里已经在一些答案以及《实用程序员》一书中读到,输入参数的验证是调用者的责任。 因此,这意味着我应该在调用函数之前验证输入参数。调用该函数的任何地方。这就提出了一个问题:不是在调用函数的所有地方都产生了检查条件的重复吗? 我对空条件不感兴趣,但对任何输入变量的验证(sqrt函数的负值,被零除,状态和邮政编码的错误组合或其他任何东西)都不感兴趣。 有一些规则如何决定在哪里检查输入条件? 我在考虑一些争论: 当无效变量的处理方式可能有所不同时,最好在调用方进行验证(例如,sqrt()函数-在某些情况下,我可能想使用复数,因此我在调用方中处理条件) 当每个调用者的检查条件都相同时,最好在函数内部进行检查,以避免重复 调用方中输入参数的验证仅在使用此参数调用许多函数之前进行。因此,在每个函数中验证参数无效 正确的解决方案取决于具体情况 我希望这个问题不能与其他任何问题重复,我搜索了这个问题,发现了类似的问题,但是他们没有确切提及此案。

7
在C和C ++中,哪些方法可以防止在需要等价(==)的情况下意外使用工作分配(=)?
在C和C ++中,编写带有严重错误的以下代码非常容易。 char responseChar = getchar(); int confirmExit = 'y' == tolower(responseChar); if (confirmExit = 1) { exit(0); } 错误是if语句应该是: if (confirmExit == 1) 按照编码,它将每次退出,因为confirmExit发生了变量分配,然后confirmExit将其用作表达式的结果。 是否有防止这种错误的好方法?

10
良好的编码风格对于决定雇用程序员的重要性有多大?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 即使是学生,我也被要求查看未(未通过)测试的程序员的代码(在android上创建斐波那契数字的列表)。 虽然我对编码样式非常严格,但我只是读到有人使用的“块”样式(请阅读注释!)。 在我的职位上,我建议不要雇用使用这种风格的人。该代码与我所使用的编码风格完全相反。 在寻找编码风格以及如何解决编码风格不足时,我很好奇一件事:我是否应该聘请一个会严重的麻烦 适应公司使用的编码风格? 请:这一般不应该是关于编码风格的讨论,那是更好的选择。关于聘请决定的编码风格的重要性! 更多信息: 我不是做出决定的人,我只是根据代码给出我的意见。这个家伙必须通过一次面试,我们的负责人都要检查软技能。如果他通过了这一点,那么他就必须通过我们的小技巧测试,这是有时要求我检查书面代码的地方。我不能说是或否。我只想知道编码样式对我的审查应该有多重要...

5
创建编码标准文档
我在一家控制系统公司工作,主要工作是SCADA和PLC以及其他控制系统。 除非决定创建内部项目管理和评估系统,否则软件开发实际上不是公司要做的事情。 这个项目最初是由来这里从事软件工作的人们承担的,我们大多是初级的。 该项目起初很小,所以我们只记录设计,数据库等内容,但我们从未真正同意编码格式/惯例。 我们开始使用StyleCop来确保我们已编写了完整的代码,但是我认为我们需要一个正式的文档来编写编码约定/实践,以便我们可以继续制定一个良好的标准,并且如果将来还有其他重要的开发工作(无论谁在此工作),具有良好的底板。 问题就出在这里,我不知道如何起草编码惯例和标准的文档,我所能想到的只是良好实践与不良实践的例子(例如,在命名变量,避免匈牙利符号等情况下的驼峰案例),我们都是能干足够的程序员(显然),但是我们只是没有关于这类东西的章程。 首先,我的问题是:好的编码标准文档的关键方面和内容是什么?

2
现在,并不是Java接口中的所有方法声明都是公共抽象的,是否应该使用这些修饰符来声明方法?
从Java 8开始,default方法被引入接口。有效地,这意味着并非in中的所有方法interface都是abstract。 从Java 9(也许)开始,private将允许使用方法。这意味着并非in中的所有方法interface都是public abstract。 问题“在Java接口中的方法是否应使用publicaccess修饰符声明?” 在/programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-m的堆栈溢出中被询问 那里,大多数答案都认为public abstract不应使用,因为中的任何方法都interface不能是public abstract。这已不再是这种情况。 因此,鉴于接口的这些新功能,是否应该public abstract在Java接口方法声明中使用关键字? 在我的特定环境中,我们将有一些经验丰富的软件工程师,但没有Java经验的人会不时读取Java代码。我觉得,public abstract对于那些不熟悉接口如何具有使用这些关键字的不同规则的历史的人来说,现在将关键字排除在外会造成更多的困惑。

3
什么时候在命令行应用程序中使用颜色合适?
目前,我在C中有一个名为的命令行应用程序btcwatch。它具有一个-C可以作为参数接收的选项,该选项将比特币的当前价格与预先存储的价格进行比较。-S。使用此选项的示例输出是: $ btcwatch -vC # -v = verbose buy: UP $ 32.000000 USD (100.000000 -> 132.000000) sell: UP $ 16.000000 USD (100.000000 -> 116.000000) 难题是是否要为UP或DOWN字符串使用颜色(分别为绿色和红色)。我知道的大多数命令行应用程序(除git之外)在输出中都远离颜色。在我希望btcwatch外观和相当“标准”(使用getopt,Makefiles等)的愿望中,我不确定在这种情况下颜色是否看起来不合适。

3
有人可以向我解释C#的编码约定吗?
我最近开始使用Unity3D,主要是使用C#编写脚本。正如我通常使用Java编程一样,两者之间的差异并不是很大,但是我仍然提到速成课程,只是为了确保自己走上正确的道路。 但是,我对C#的最大好奇是它使用了其方法名称的首字母大写(例如Java:getPrime()C#:GetPrime()aka:Pascal Case?)。是否有充分的理由呢?我从速成课程页面上了解到,我读到的显然是.Net的约定,我无法更改它,但是我很好奇,为什么听到这样的结果而不是正常的(相对的)骆驼案呢?例如Java使用的 注意:我了解语言具有自己的编码约定(Python方法都是小写字母,这也适用于此问题),但是我从来没有真正理解过为什么它没有被正规化为标准。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.