Questions tagged «coding-style»

我们有一个小的开发团队（只有3个开发人员），最近我们有了一个新的团队成员。虽然他是一个聪明的编码器，但是他的编码风格与我们完全不同。我们现有的代码库主要包含可读，干净和可维护的代码，但是新团队成员正在迅速更改许多文件，引入难看的hack和快捷方式，在各处使用定义，在错误的位置添加功能等。 我的问题是，其他人以前是否经历过这种情况，以及是否有人有与他交谈的技巧。

14 coding-style  coding-standards 

考虑冲突标记。即： <<<<<<< branch blah blah this ======= blah blah that >>>>>>> HEAD 在促使我提出此问题的特殊情况下，负责的团队成员刚刚完成了从上游到我们分支的合并，并在某些情况下将其留为注释，以作为刚刚过去的文档解决。他将其置于编译状态，测试通过，因此它没有您想的那么糟糕。 尽管本能地，我真的对此表示反对，但是作为恶魔的拥护者，我可以理解为什么他会这样做： 因为它向其他团队开发人员强调了合并带来的变化。 因为那些在特定代码方面更精通的人然后可以解决注释所说明的问题，从而使他不必猜测。 因为上游合并是很痛苦的事情，并且可能难以证明有时间妥善解决所有问题的时机，所以需要一些半完全的FIXME通知，因此为什么不使用原始冲突作为注释来记录此问题。 我的反对是本能的，但我希望能够合理地证明其合理性，或者更明智地看待我的立场。任何人都可以给我一些例子，甚至是一些经历，其中人们与其他人在一起做得不好，和/或为什么这样做不好的原因（或者您可以扮演魔鬼的拥护者并予以支持）。 我自己直接担心的是，如果我一直在编辑有关文件之一，拉出更改，遇到真正的冲突，但也加入评论的文件，那显然会很烦人。那我确实会有一个非常混乱的文件。幸运的是，这没有发生。

14 version-control  comments  coding-style 

除非需要区分具有相同名称的变量和字段，否则我永远不会放在this.字段或C＃中的任何成员访问前面。我认为这与m_C ++中常用的前缀没有什么不同，并且认为如果您确实需要指定它是成员，则您的类太大。 但是，我办公室中有很多人对此表示强烈反对。 当前认为最佳做法是this.什么？ 编辑：为了澄清，我从不使用m_，仅this.在绝对必要时使用。

14 c#  coding-style 

最近开始担任软件开发人员的第一份工作时，有人被告知我不必在代码中遵循任何命名约定。由从事其他较大项目的小组编写的代码遵循命名约定，但是由于我被邀请编写一个新的独立应用程序，因此感觉并不重要。这是我最后的担心，所以我只是采用了现有的惯例并予以遵守。 int nTickCount bool bConnected object[] m_aItems fSum += fWeight * fValue class cManager enum etSystemStates etSystemStates eState cManager.cs 但这真的值得吗？我发现很难判断遵循这种命名约定对理解和检测错误的最终效果，但是，从视觉上看，它看起来很丑陋。另外，在项目中拥有名为cSomething的每个类和文件似乎很精明。 与具有明显不同的事物（例如您所采用的算法和体系结构）相比，我并不觉得这有什么大不了的。但是任何影响我编写的每一行代码的约定似乎都应该正确。 如果完全需要使用一种命名惯例，您会发现什么是最优雅，最有效的命名惯例？它表示类型和/或范围吗？

14 language-agnostic  coding-style  notation  hungarian 

我正在阅读Bob叔叔的Clean Code。由于我不是讲英语的人，因此我无法理解以下陈述： 类和对象应该有像名词或名词短语的名称 Customer，WikiPage，Account，和AddressParser。避免的话想 Manager，Processor，Data，或Info在类的名称。类名不能是动词。 据我所知，没有一个Manager，Processor，Data和Info是一个动词，是不是？他想强调的重点是什么？

14 coding-style  terminology  code-quality  naming 

如果运行静态分析工具（例如PMD，StyleCop / FxCop）的持续集成服务器是否应实施编码标准/样式，并且如果未遵循标准，则构建失败？哪些类型的规则不应用于使构建失败？

14 coding-style  coding-standards  continuous-integration 

基本情况可能是每个人都熟悉的。您已经在团队中就某些编码标准达成了共识，现在是时候确保每个人都遵循它们了。 有些通过繁重的配对编程来完成，有些则维护编码标准列表并进行手动检查。其他人甚至使用Visual Studio中的静态代码分析工具来确保实施了编码标准。 您有什么最佳实践来确保编码标准？您使用哪些工具-每个开发人员都应该知道一些基本工具吗？您如何将代码的标准化集成到开发工具中？

14 c#  .net  coding-style 

我正在AngularJS项目上工作，并且我的许多HTML元素中的属性很多： <button type="submit" ng-click="Page.UI.DetailView.ExecuteFunction()" ng-disabled="step5.$invalid" class="btn btn-success pull-right"> Submit this Product </button> 这些属性的顺序是否存在标准化约定？按字母顺序？按含义分组（例如，所有角度属性一起）？首先是标准HTML属性（例如“类型”）？

13 programming-practices  coding-style  html 

问题：两个开发人员=>对缩进有三点意见，是否在换行符上加上大括号等等。 我们通常在项目中与三到四个人一起工作，每个人都有自己的代码风格。我知道，常见的解决方案是在每个人都必须使用的代码风格上达成共识，但是我不想强迫有创造力的程序员穿着不适合他们的西装。 所以问题是：有没有办法让每个程序员都保持自己的风格，但是在存储库中有一个通用的代码库？我想到了一些git / svn / whatever插件，它们在签出和提交时在个人样式和通用样式之间变化。在我看来，此方法中的棘手部分是支持文件版本之间的正确差异

13 coding-style 

我在两个月前加入了六个开发团队。人很好，一切都很好。但是越来越多的我观察到一种特别的心态。东西很快就被修复了，但以将来的可用性为代价，几乎没有测试，两个人高兴地承认，他们喜欢把知识带到脑海中，而不是写下来。 该如何处理？我想以身作则，但时间有限-我喜欢架构和实际实现这些东西。但是我担心，临时的心态会感染我，而不是在设计和代码上力求清晰，简单（这并不容易建立），我被无休止的黑客循环激化了-这没有局外人可以解耦-仅出于进度和管理的考虑。

13 architecture  coding-style  management  technical-debt 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我在Python和Java上做了很多工作，并且这两种语言都有关于标识符中如何使用大写字母的相当通用（尽管不是通用的）约定：都PascalCase用于类名和ALL_CAPS“全局”常量，但用于其他标识符很多Java代码使用，mixedCase而很多Python代码使用underscore_delimiters。我知道没有语言或库会强制使用任何特定的大写字母，但是我发现当我坚持使用的语言的标准约定时，我的代码似乎更具可读性。 现在，我正在用C ++启动一个项目，并且我想应用相同的想法。我应该了解任何最常见的大写约定吗？

13 c++  coding-style  coding-standards 

我试图提出一个更好地记录我的代码的观点，尤其是在涉及类成员的XML注释时，但通常感觉很傻。 对于事件处理程序，命名约定和参数是标准且清晰的： /// <summary> /// Handler for myCollection's CollectionChanged Event. /// </summary> /// <param name="sender">Event Sender</param> /// <param name="e">Event Arguments</param> private void myCollection_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e) { // actual code here... } 我还经常使用简单的属性（IMO）来明确命名，因此摘要是多余的： /// <summary> /// Indicates if an item is selected. /// </summary> public bool ItemIsSelected { get { …

13 c#  coding-style 

如何为复杂的复合AND / OR if语句设置样式，以实现最大的可读性？您如何缩进以及将换行符放在何处？我的特殊情况如下。绝对比将所有内容都粉碎成一条线要好，但是看起来仍然很凌乱。 if ( ( x == y && a != b && p.isGood() && ( i + u == b || q >= a ) ) || k.isSomething() || m > n ) { doSomething(); }

13 coding-style  indentation 

我目前正在处理一组报告，这些报告包含许多不同的部分（均需要不同的格式），并且我正在尝试找出构造代码的最佳方法。我们过去完成的类似报告最终都具有非常大的功能（超过200行），这些功能可以对报告进行所有数据处理和格式化，从而使工作流看起来像这样： DataTable reportTable = new DataTable(); void RunReport() { reportTable = DataClass.getReportData(); largeReportProcessingFunction(); outputReportToUser(); } 我希望能够将这些大功能分解为较小的块，但恐怕最终我将拥有数十个不可重用的功能，而类似的“在这里做所有事情”功能的唯一作用是调用所有这些较小的函数，如下所示： void largeReportProcessingFunction() { processSection1HeaderData(); calculateSection1HeaderAverages(); formatSection1HeaderDisplay(); processSection1SummaryTableData(); calculateSection1SummaryTableTotalRow(); formatSection1SummaryTableDisplay(); processSection1FooterData(); getSection1FooterSummaryTotals(); formatSection1FooterDisplay(); processSection2HeaderData(); calculateSection1HeaderAverages(); formatSection1HeaderDisplay(); calculateSection1HeaderAverages(); ... } 或者，如果我们更进一步： void largeReportProcessingFunction() { callAllSection1Functions(); callAllSection2Functions(); callAllSection3Functions(); ... } 这真的是更好的解决方案吗？从组织的角度来看，我认为是这样（即，一切都比可能的组织得要好得多），但是就代码的可读性而言，我不确定（可能只调用其他函数的功能链很大）。 有什么想法吗？

13 coding-style 

这个问题的灵感来自java中的一个问题final。 在C / C ++中，应const尽可能使用？ 我知道已经有一个关于const在参数中使用的相关问题。不幸的是，这个问题及其答案不能完全回答我的问题，因为它仅与函数参数有关，但我也想了解其他情况（例如：局部变量）。 另外，几乎所有该问题的答案都说我们应该使用，const因为它包含有关变量可访问性的有用信息。但这似乎与在Java中使用final的答案相抵触，因为final如果其中不包含额外的信息，状态可能是多余的，因此应省略它以使代码简洁明了。 那么，我应该const尽可能使用吗？如果是这样，为什么constC ++中的建议final与Java中的建议不同？

13 c++  coding-style  const