Questions tagged «coding-style»

是否有任何推荐的/普遍接受的编码样式用于处理以下情况：函数返回一个值的元组，但之后仅使用这些值中的一个（请注意，这主要是我无法更改的库函数的意思–编写包装器这个电话可能有点矫kill过正...）？而不是做 a, b, c = foo() 然后不使用band c，则应首选以下哪个变体（或还有另一个变体？）： 变体1（下划线） a, _, _ = foo() （这非常简单明了，但可能会_ = gettext.gettext在许多使用翻译的应用程序中使用） 变式2（虚拟名称） a, unused, unused = foo() （我认为这不是很吸引人，其他名称也是如此dummy） 变体3（索引） a = foo()[0] （对我来说，这些()[0]看起来很不可思议……）

30 python  coding-style 

当您与倾向于编写风格上很差的代码的人一起工作时，您会怎么办？我正在谈论的代码在技术上通常是正确的，结构合理的，甚至在算法上可能是优雅的，但看起来却很丑陋。我们有： 不同命名约定和标题的混合（underscore_style和camelCase和UpperCamel以及CAPS全部或多或少地随机应用于同一函数中的不同变量） 奇异且不一致的间距，例如 Functioncall (arg1 ,arg2,arg3 ); 注释和变量名中很多拼写错误的单词 我们有一个很好的代码审查系统，可以正常工作，因此我们可以仔细研究并修复最糟糕的问题。但是，发送包含50行“在此处添加空格。正确拼写'itarator'。更改此大写字母等”的代码审核确实很琐碎。 您如何鼓励这个人更加小心并与这些细节保持一致？

30 coding-style  code-quality  teamwork  code-reviews 

该编程样式文档有一条通用规则，即： 如果强烈反对这些规则，则可能违反这些规则。 这与我的思维方式相冲突，并且有很多文章说编码风格实际上很重要。例如，这说： 编码标准文档告诉开发人员如何编写代码。他们将代替所有开发人员按照自己喜欢的样式进行编码，而是将所有代码编写为文档中概述的标准。这样可以确保以一致的方式对大型项目进行编码-不同的程序员不会以不同的方式编写部分内容。此解决方案不仅使代码更易于理解，而且还确保任何查看该代码的开发人员都将知道整个应用程序的期望。 因此，我是否误解了本文档以及该问题顶部的引文中的内容？人们真的可以忽略编码样式吗？ 也许我还不够清楚，所以通过这次编辑，我将澄清一下。 我正在为我们的团队编写编码样式文档，我想使用一些静态分析器检查样式。如果失败，詹金斯将发送电子邮件。如果样式不匹配，我想使代码审查失败。这显然与第一个引用冲突。 但是，如果引用正确，那么如果任何人都可以做自己想做的事情，那么编码样式文档的用途是什么？

30 coding-style 

您最喜欢的声明指针的方法是什么？ int* i; 要么 int *i; 要么 int * i; 要么 int*i; 请解释原因。 另请参见：http : //www.stroustrup.com/bs_faq2.html#whitespace

30 c  coding-style  pointers 

我正在为团队编写JavaScript样式指南，以便我们可以更轻松地组织和贡献文档。但是我遇到了一个小障碍，这就是我的问题所在... 我应该如何调用立即调用的匿名JavaScript函数。我知道我可以简单地将其称为“匿名函数”，但我想强调一下它被立即调用的事实。 这是一个例子： var MyVariable = (function(data){ return "another value" })("some value"); console.log(MyVariable); // "another value"

29 javascript  coding-style  terminology 

现在，我在C ++代码中使用了Google C ++样式指南，对此我感到非常满意。 最近有人告诉我，该指南非常糟糕：Google内部使用（我知道），该指南已经过时，并且推广了一些非常糟糕的做法。所以我想使用另一种编码风格。 有哪些良好且使用合理的C ++样式指南？我为gcc和Visual Studio编写代码，并且使用了许多C ++ 11功能。 我最喜欢Google C ++样式指南的是缩进，空格和命名约定（特别是所有类，类型（包括typedef，类型别名和模板别名）都以大写的首字母命名）。 我知道任何答案都是主观的（希望在此站点上可以），并且希望您提出任何意见，但我对最近使用的指南很感兴趣。

29 c++  coding-style  c++11 

我是程序员，是第一份真正的工作，但是由于使用的编码风格，我无法解决任何问题。这里的代码： 没有评论 没有功能（依次执行50、100、200、300或更多行） 使用很多if带有很多路径的语句 有变数，就没有任何意义（例如：cf_cfop，CF_Natop，lnom，r_procod） 使用旧的语言（2002年的Visual FoxPro 8），但2007年有新版本。 我感觉自己已经回到了1970年。对于熟悉OOP，干净代码，设计模式等的程序员来说，以这种老式方式进行编码遇到麻烦是正常的吗？ 编辑：所有的答案都很好。对于我的（未）希望，看来世界各地有很多这种代码库。所有答案中提到的一点是重构代码。是的，我真的很喜欢这样做。在我的个人项目中，我总是这样做，但是...我无法重构代码。程序员仅可在其设计任务中更改文件。 旧代码中的每个更改都必须在代码中保留注释（即使使用Subversion作为版本控制），还要保留与该更改相关的元信息（日期，程序员，任务）（这变得一团糟，其中的代码包含3条使用过的代码行和50条代码旧行评论）。我认为这不仅是代码问题，而且是软件开发问题的管理。

29 coding-style 

尽管Sun的Java代码约定建议将换行符放在操作员之前，但许多其他准则也对此表示反对。我看不出任何明显的利弊，因此使用其中一种样式相对于另一种样式是否有优势？ String longVarName = a + b + c + d + e + f; 与 String longVarName = a + b + c + d + e + f;

29 java  coding-standards  coding-style 

HTML / CSS开发有很多类比。对于初学者来说可能会有些混乱。 HTML =地基/房屋 CSS =墙壁/蓝图/墙纸 这里有什么最佳实践吗？我们应该首先写哪一个？

28 coding-style  html  css 

我已经编程了两年，经常发现自己陷入了困境。 有两种解决方案- 一种是简单的，即简单的方法，易于理解和维护。它涉及一些冗余，一些额外的工作（额外的IO，额外的处理），因此不是最佳的解决方案。 但是其他方法则使用复杂的方法，难以实现，通常涉及许多模块之间的交互，是一种高效的解决方案。 当我没有硬性能SLA甚至简单的解决方案都可以满足性能SLA时，我应该争取哪种解决方案？我对开发人员的简单解决方案不屑一顾。 如果您的性能SLA可以通过一个简单的解决方案来解决，那么提出最佳最佳复杂解决方案是一种好习惯吗？

28 design  programming-practices  coding-style  code-quality  performance 

问题： 和值中的语法有哪些实际考虑因素？classid 请注意，我并不是在询问语义，即所使用的实际单词，例如本博客文章中所述。命名约定方面已经有很多资源，事实上，这使我对各种语法位的实用信息的搜索变得困难，这些信息包括：-大写，插补（特别是破折号）的使用，要使用或避免的特定字符等。 总结一下我问这个问题的原因： 命名限制的ID和类不自然导致任何约定 命名约定在语义方面的资源丰富，使得对句法方面的考虑变得模糊 我在此找不到任何权威来源 SE程序员对此主题还没有任何问题:) 我考虑过使用的一些约定： UpperCamelCase，主要是作为服务器端编码的交叉习惯 lowerCamelCase，与JavaScript命名约定保持一致 css-style-classes，这与css属性的命名一致（但在选择Ctrl + Shift + ArrowKey文本时可能会令人讨厌） with_under_scores，我个人没见过用过 alllowercase，简单易记，但长名称很难读 UPPERCASEFTW，这是惹恼其他程序员的好方法（可能与选项4结合使用以提高可读性） 可能我也遗漏了一些重要的选项或组合。那么：命名约定有哪些考虑因素，它们导致了哪些约定？

28 coding-style  naming  html  coding-standards  css 

我是一个相当年轻的程序员，我在一家中型公司的IT部门工作。我有一个同事，他是一个非常好的Visual Basic 6程序员。我的意思是非常好。老实说 在我需要喝第一杯咖啡并启动机器时，他可以交付工作中的应用程序，其中包含的错误很少。他就是那么好。 事实是，我们正在与一个团队合作，他的工作风格完全过时。他不相信版本控制软件（如果您只是确保代码正确，就不需要所有的废话）。不相信部署（我可以交付一个可运行的可执行文件。如何部署该文件供系统管理员了解）。不相信抽象。（''如果您想创建一个子例程，请继续，但是不要从该子例程中调用任何子例程。这样会造成混乱，并且代码也很难遵循。这样，每个人都可以遵循该过程中的每个步骤。 ”或“是的，请确保您可以使用该库为您完成此操作，但是那样您就不会真正了解正在发生的事情”），当然也不相信OOP。（我们在VB.net中工作） 他的工作非常出色，可以比我更快地交付应用程序。但这在团队中是行不通的。我们的其他团队成员很安静，尽管他倾向于同意，但他不喜欢大声说出来。我们的经理认为我是有根据的，但不是程序员。 我很难维护他编写的程序，但这并不能营造良好的团队氛围。您认为对我来说最好的事情是什么？

28 coding-style  teamwork 

诸如Fortify之类的静态代码分析器会在一个finally块内抛出异常时说“抱怨” Using a throw statement inside a finally block breaks the logical progression through the try-catch-finally。通常我同意这一点。但是最近我遇到了以下代码： SomeFileWriter writer = null; try { //init the writer //write into the file } catch (...) { //exception handling } finally { if (writer!= null) writer.close(); } 现在，如果writer无法正确关闭，则该writer.close()方法将引发异常。应该抛出异常，因为（很可能是）写入后未保存文件。 我可以声明一个额外的变量，如果关闭时出错，则进行设置，writer并在finally块之后引发异常。但是这段代码可以正常工作，我不确定是否要更改它。 在finally块内引发异常的缺点是什么？

27 coding-style  exceptions  exception-handling 

我发现自己在写很多这样的代码： int myFunction(Person* person) { int personIsValid = !(person==NULL); if (personIsValid) { // do some stuff; might be lengthy int myresult = whatever; return myResult; } else { return -1; } } 它可能会变得非常混乱，特别是如果涉及多个检查。在这种情况下，我尝试了多种样式，例如： int netWorth(Person* person) { if (Person==NULL) { return -1; } if (!(person->isAlive)) { return -1; } int …

27 coding-style  language-agnostic 

我听说过很多关于使方法简短的知识，而且我听过很多程序员说，在方法中使用#region标记是一个确定的信号，即它太长了，应该重构为多个方法。但是，在我看来，在许多情况下，在方法中使用#region标签分隔代码是重构为多个方法的绝佳解决方案。 假设我们有一种方法，其计算可以分为三个相当不同的阶段。此外，这些阶段中的每个阶段仅与该方法的计算有关，因此将它们提取到新方法中不会获得代码重用。那么，将每个阶段提取到自己的方法中有什么好处？据我所知，我们获得的是每个阶段都有一定的可读性和单独的变量范围（这将有助于防止对特定阶段的修改意外破坏另一个阶段）。 但是，这两种方法都可以实现，而无需将每个阶段提取到自己的方法中。区域标签使我们可以将代码折叠成可读性强的形式（其附加好处是，如果我们决定扩展和检查代码，则不再需要在该文件中保留位置），并且只需将每个阶段包装在{}创建自己的工作范围。 这样做的好处是，我们不会使用实际上仅与第四个方法的内部工作相关的三个方法来污染类级别的范围。在我看来，立即将长方法重构为一系列短方法似乎是等同于过早优化的代码重用。您正在引入额外的复杂性以解决在许多情况下永远不会出现的问题。如果有出现代码重用的机会，您以后总是可以将阶段之一提取到其自己的方法中。 有什么想法吗？

27 c#  coding-style