Questions tagged «coding-style»

是否有客观的论据支持或反对使用对象vs唯一ID作为方法/函数参数？（以及其他对象的成员？）。特别是在静态类型语言（C＃/ Java / Scala）的上下文中 对象本身的优点： 更多类型安全的调用。使用ID时，存在参数错误排序的风险。尽管可以通过为每个仅保留该类ID的类保留一个“ mini”类来缓解这种情况。 从持久中获得一次，无需再次获得 使用ID时，如果id类型发生更改，例如int-> long，则将要求全面更改，并且可能会出错。.（courtsey：https ://softwareengineering.stackexchange.com/a/284734/145808 ） 使用ID的优点： 在大多数情况下，不需要唯一的对象，只需要uniqueid即可，因此拥有ID可以节省从持久性获取ID的时间。 据我所知，将这些技术混合使用既有弊又无利。 鉴于这是一个具体定义的问题，我希望有客观的答案，而不是-“我认为”或“我喜欢”类型... :-)。 编辑：评论者建议的上下文-唯一的限制是静态类型的语言。该应用程序是一个通用应用程序，尽管也很高兴能够根据特定的使用场景获得答案。 编辑：更多的上下文。说我有一个图书管理系统。我的模型是： Book: { id: Int, isbn: String, donatedBy: Member, borrowedBy: Member } Member: {id: Int, name: String} Table- wishlist: { isbn: String, memberId: Int} Table- borrows: { id: Int, memberId: Int} Method: …

10 coding-style  methods  parameters 

我和我的研发团队维护着庞大的代码库。我们已经将业务逻辑分为多个包。其中一些具有相同名称的类。 如您所料，当在同一Java文件中引用两个类时，名称冲突。 例如： com.myapp.model (package) - Device (class) - ... com.myapp.data (package) - Device (class) - ... 我们就治疗这些病例的最佳实践进行了辩论，并提出了以下选择： 第一种选择 重命名类，添加前缀 ModelDevice DataDevice 第二选择 同时引用包和类的完整名称 com.myapp.model.Device com.myapp.data.Device 在代码管理和可伸缩性方面，更正确的是什么？ 我们目前正在混合使用这两种方法，并开始出现不一致之处

9 java  coding-style  coding-standards  naming  conventions 

因此，我正在基于数据库中的两个人创建一种称呼行的方法。 有四个参数：两个名称（name1和name2）和两个性别（gender和gender2）。 对于每种性别组合，我都有不同的输出。 例如：如果性别1为M（man）且性别2也为M，则输出应为： Dear Sir name1 and Sir name2, 此时，我的开关如下所示： switch(gender1){ case 'M': switch(gender2){ case 'M': printf("Dear Sir %s and Sir %s", name1, name2); break; case 'W': printf("Dear Sir %s and Madame %s", name1, name2); break; case 'R': ... } break; case 'W': switch(gender2){ case 'M': printf("Dear Madame %s …

9 design-patterns  coding-style  clean-code  switch-statement 

当我最近在一家大公司工作时，我注意到那里的程序员遵循这种编码风格： 假设我有一个函数，如果输入为A，则返回12；如果输入为B，则返回21；如果输入为C，则返回45。 所以我可以将函数签名写为： int foo(String s){ if(s.equals("A")) return 12; else if(s.equals("B")) return 21; else if(s.equals("C")) return 45; else throw new RuntimeException("Invalid input to function foo"); } 但是在代码审查中，我被要求将功能更改为以下内容： int foo(String s){ HashMap<String, Integer> map = new HashMap<String, Integer>(); map.put("A", 12); map.put("B", 21); map.put("C", 45); return map.get(s); } 我不能说服自己为什么第二个代码比第一个更好。第二个代码肯定会花费更多的时间来运行。 使用第二个代码的唯一原因可能是它提供了更好的可读性。但是，如果该函数被多次调用，那么第二个函数会不会减慢该实用程序调用它的运行时间？ 你怎么看待这件事？

9 coding-style  coding-standards 

我正在研究一些使用多个库（包括一些C库）的C ++代码，它们都具有不同的编码样式。一旦达到可用阶段，它将开源。对于签出代码以修复一个错误或添加一个功能的短期贡献者，这将给他们带来最少的混乱？ 即使整个应用程序偶尔与所使用的库的典型编码风格都不匹配，在整个应用程序中也要具有一种一致的编码风格。 当某个模块中大量使用某个库时，请遵循该模块中该库的典型编码样式（即该库自己的代码和文档中使用的编码样式）。 我的想法是，后者将使该特定库中的专家更容易做出一次性贡献，并使得在开发过程中合并教程/示例代码更加容易。但是，这也使整个应用程序中的编码样式不一致。每种方法的优缺点是什么？

9 coding-style 

我刚刚开始使用节点，并且我很快注意到的一件事是回调能够以多快的速度建立到一个愚蠢的缩进级别： doStuff(arg1, arg2, function(err, result) { doMoreStuff(arg3, arg4, function(err, result) { doEvenMoreStuff(arg5, arg6, function(err, result) { omgHowDidIGetHere(); }); }); }); 该负责人风格指南说，把每个回调在一个单独的功能，但似乎对使用封闭的过于严格，并使单个对象在顶级声明可用几层下来，对象必须通过所有的传递中间回调。 可以使用函数范围来帮助吗？将所有需要访问全局对象的回调函数放在声明该对象的函数中，以便将其放入闭包中？ function topLevelFunction(globalishObject, callback) { function doMoreStuffImpl(err, result) { doMoreStuff(arg5, arg6, function(err, result) { callback(null, globalishObject); }); } doStuff(arg1, arg2, doMoreStuffImpl); } 等等更多的层... 还是有框架等可以帮助减少缩进级别而无需为每个回调都声明命名函数？您如何处理回调金字塔？

9 node.js  coding-style 

我所在的研发团队已决定采用编码标准。我们只是最近才成立的，我们自己的代码和通用编码时间太少，无法将我们的标准/惯例文档建立在我们团队有机发展的基础上，也无法借鉴我们自己的代码中的良好示例等。 现在，我们每个人都有一些过去工作场所的经验-尽管我们每个人都没有处于这样一种状态：“让我们在这里采用这份全面的文件，我发现它适合我们在这里从事的工作”（*）。另外，我们中的某些人（包括我本人）只有没有官方编码标准的地方的经验，或者在不同的环境中用不同的语言编写（高压每周发布的生产环境，而不是更加注重研究的开发工作） 因此，我一直在考虑的一种选择是获取一个相对知名且备受关注的文档，剪掉我们不在乎/关心的内容，并根据我们的偏好进行一些修改。 这是常见的做法吗？您认为这是个好主意吗？如果是这样，那将是一个合理的“基准”编码标准（不要告诉我哪个是最好的，我不想在这里引发宗教冲突；只需指出可以在其基础上进行全面或“中立”的内容） ） 笔记： 我们希望可以使用C，C ++，OpenCL，CUDA，Python。 我们是一个由4人+经理组成的团队，预计在一年左右的时间内增长到大约5-6。 在我们公司中，团队几乎完全是自治的，通常根本不互动（甚至不使用彼此的代码-工作是在完全不同的项目上）；所以-没有公司范围内的考虑。 关于工具，目前我们知道我们将使用Eclipse，因此它的代码格式化程序至少将成为一种工具。Ctrl + Shift + F很久以来就是我的朋友 在编写Java时，我采用了尽可能严格遵循Bloch的Effective Java的做法。现在，这还不是一个编码标准，但是您可以将一些砖，水泥和砂浆称为编码标准。我当时正在考虑将类似的内容作为“混合”的一部分（注意我们不使用Java）。 我指的是更广泛意义上的编码标准，例如采用对P.SE问题的回答中提出的建议。 我找到了大量的C ++编码标准文档 ; 也许我应该挖掘我们的基线。 （*）并非完全正确，但我不想使这个问题复杂化。

9 c++  c  coding-style  coding-standards  team 

我习惯用Java的分号来分隔语句，所以自然也用Scala代码来完成。我还认为代码更易于阅读，因为很明显一个语句在哪里结束而另一个语句在哪里开始。但是很多时候，当我在SO上发布一段Scala代码时，代码被编辑只是为了删除分号。 是否应该使用分号？是否有任何“官方”准则或编码风格？ 是否有需要分号的情况，否则代码不明确？

9 coding-style  scala 

我认为，#include对于CPP文件中使用的任何类型的标头，通常都是一种好习惯，无论该HPP文件中已经包含了什么。因此#include <string>，例如，即使在CPP中跳过它，我仍然可以编译，但我可能同时在HPP和CPP中使用。这样，我不必担心我的HPP是否使用前向声明。 是否有任何工具可以强制执行此#include编码样式？我应该执行这种编码样式吗？ 由于预处理器/编译器不在乎#include是来自HPP还是CPP，因此如果我忘记遵循这种样式，则不会得到任何反馈。

9 c++  coding-style  include 

我才知道你会写 '{}{}'.format(string_a, string_b) 代替 '{0}{1}'.format(string_a, string_b) 在Python中，即，当您希望事物按顺序逐一排列时，可以省略字符串格式参数的数字。 这被认为是Pythonic吗？ 注意：“ Pythonic”是Python程序员中常用的术语，表示惯用的Python代码。在Python文化中，对于样式问题，尤其是对于像这样的非常具体的问题，人们倾向于达成明确的共识，因为该语言的明确设计理念是：“应该有一个-最好只有一个-显而易见的方式。” 这是从“ Python的禅宗”一书中引用的，这是一组格言，在定义什么是“ Pythonic”方面有很长的路要走，并且包含在Python的每个发行版中（在任何Python解释器命令行中，都import this可以看到它）。

9 coding-style  python 

考虑一下这段代码： if (x == 1) { throw "no good; aborting" ; } [... more code ...] 现在考虑以下代码： if (x == 1) { throw "no good; aborting" ; } else { [... more code ...] } 这两种情况的工作方式完全相同。第一种情况的优点是您不必将其余代码“括入”中else。第二个优点是遵循显式具有elsefor每个的实践if。 任何人都可以提供任何有力的论据来支持一个胜于另一个吗？

9 coding-style  exceptions 

几周后，我的项目将结束，我想开始准备好代码供其他人使用。 我将把所有内容发布到GitHub，以便人们可以对其进行调整，并希望使其更好。 我想我要问的是，确保我的代码被充分记录并措辞正确以供他人使用的最佳方法是什么？ 我知道您应该始终注释所有内容，并且我将为每种方法添加@params功能，但是一般是否还有其他提示？

9 coding-style  coding-standards  github 

假设我们有一些代码，用于在页面加载时初始化事物，看起来像这样： function initStuff() { ...} ... $(document).ready(initStuff); 仅从代码段的第三行调用initStuff函数。再也不。因此通常人们将其放入这样的匿名回调中： $(document).ready(function() { //Body of initStuff }); 将函数放在代码中的专用位置并不能真正帮助提高可读性，因为调用ready（）可以使这很明显是初始化代码。 还有其他理由更喜欢另一个吗？

9 coding-style  jquery 

在阅读另一位程序员的代码时，他使用了我从未见过的格式。例如 namespace MyNs.HereWeAre {//tab here for some reason public class SomeClass {//here's another tab public string Method() {//yet another tab string _variable = "";//no tab implementation return _variable; } }//eof - class (Yes these eof comments are on every file) }//eof - namespace // eof - file 我承认...此代码使我生气。很难实现这种风格。需要与IDE（Visual Studio）提供的默认格式作斗争。 如果我知道这种药理有充分的理由，我可以更容易地吞下这种药。这种风格是否源于其他编程语言/ …

9 c#  coding-style 

如今，大多数GUI工具包都使用Signals + Slots模型。没错，是Qt和GTK +率先提出的。 您知道，小部件或图形对象（有时甚至是未显示的小部件）将信号发送到主循环处理程序。然后，主循环处理程序调用为该小部件/图形对象分配的事件，回调或插槽。virtual工具包通常已经提供了默认的（大多数情况下）事件处理程序来处理所有预定义的信号，因此，与以前的设计不同，开发人员必须自己为每个消息编写整个主循环和处理程序。 （例如WINAPI），开发人员只需要担心实现新功能所需的信号。 据我所知，现在大多数现代工具箱都使用了这种设计。有Qt，GTK +，FLTK等。还有Java Swing。C＃甚至具有它的语言功能（事件和委托），并且Windows Forms已在此设计上开发。实际上，在过去的十年中，这种用于GUI编程的设计已经成为一种不成文的标准。由于它提高了生产率并提供了更好的抽象。 但是，我的问题是： 对于现代GUI编程，是否有并行或实用的替代设计？ 即信号+插槽设计是镇上唯一实用的设计吗？用任何其他设计进行GUI编程是否可行？是否有任何其他现代（最好是成功且流行的）GUI工具箱都基于替代设计？

9 design  coding-style  gui