Questions tagged «coding-style»

私有方法何时应采用公共路线访问私有数据？例如，如果我有这个不可变的“乘数”类（我知道有点作弊）： class Multiplier { public: Multiplier(int a, int b) : a(a), b(b) { } int getA() const { return a; } int getB() const { return b; } int getProduct() const { /* ??? */ } private: int a, b; }; 我可以通过两种方式实现getProduct： int getProduct() const { return a * b; …

11 programming-practices  coding-style  access-control 

我是UI开发的新手，但是我对CSS的工作方式感到不舒服。 我的用例是我想div在页面上的特定内部应用某些特定的样式。 CSS尝试： div.class1 { font: normal 12px arial, helvetica, sans-serif; font-color: #f30; } div.class1 div.class2 { border: 1px solid #f30; } 较少尝试： @red: #f30; @font-family: arial, helvetica, sans-serif; div.class1 { font: normal 12px @font-family; font-color: @red; div.class2 { border: 1px solid @red; } 该CSS版本可诱发错误的，因为它迫使你重复#f30及div.class2每次尝试实现层次结构和可变的再利用时间。 我的问题： 为什么CSS使事情变得困难？ LESS没什么特别的-只是做出了明显的改进并转换为CSS？ CSS希望激发用户什么，因为它促进了这种冗余的编码风格？ 我坚信CSS应该是LESS。绝对地，我忽略了一些为什么CSS会这样做的明显优势。我以为这是一个遗留问题，但是当我没有尝试使用CSS3解决这个问题时，我感到很惊讶。 …

11 coding-style  css  ui  css3 

我最近在Java中进行了一个中型项目的重构，以返回并添加单元测试。当我意识到模拟单例和静态模型是多么痛苦时，我终于“明白了”我一直以来一直在阅读的内容。（我是需要从经验中学习的人之一。哦。） 因此，既然我正在使用Spring创建对象并将它们连接在一起，那么我就不用去左右static关键字了。（如果我有可能要模拟它，那么它在与Math.abs（）相同的意义上并不是真正的静态，对吧？）问题是，我已经习惯于使用static来表示方法不依赖在任何对象状态下。例如： //Before import com.thirdparty.ThirdPartyLibrary.Thingy; public class ThirdPartyLibraryWrapper { public static Thingy newThingy(InputType input) { new Thingy.Builder().withInput(input).alwaysFrobnicate().build(); } } //called as... ThirdPartyLibraryWrapper.newThingy(input); //After public class ThirdPartyFactory { public Thingy newThingy(InputType input) { new Thingy.Builder().withInput(input).alwaysFrobnicate().build(); } } //called as... thirdPartyFactoryInstance.newThingy(input); 因此，这就是敏感的地方。我喜欢旧方法，因为大写字母告诉我，就像Math.sin（x）一样，ThirdPartyLibraryWrapper.newThingy（x）每次都以相同的方式执行相同的操作。没有对象状态可以更改对象执行我要执行的操作的方式。这是我正在考虑的一些可能的答案。 没有其他人有这种感觉，所以我有问题。也许我只是还没有真正内部化OO的做事方式！也许我在用Java编写，但在FORTRAN或类似语言中思考。（由于我从未写过FORTRAN，这会给人留下深刻的印象。） 也许出于论证代码的目的，我正在使用静态作为不变性的一种代理。话虽这么说，有什么线索 要我在我的人一起，以保持它的到来代码知道什么是有状态的，什么不是？ 如果我选择好的对象隐喻，也许应该只是免费提供？例如thingyWrapper，听起来好像它的包装状态是独立的，而包装状态Thingy本身可能是可变的。同样，thingyFactory听起来应该是不变的，但在创建时可能会选择不同的策略。

11 coding-standards  readability  coding-style  static-methods 

是否有用于注释正则表达式的通用方法：内联注释引用RegEx的不同部分或针对所有表达式的常规注释？

11 documentation  coding-style  comments 

将样式应用于body标签将应用于整个页面，因此 body { font-family: Verdana } 将应用于整个页面。这也可以用 * {font-family: Verdana} 这将适用于所有元素，因此似乎具有相同的效果。 我了解这样的原理：在第一种情况下，样式将应用于整个页面的主体一个标签，而在第二种示例中，将字体应用于每个单独的html元素。我要问的是这样做的实际区别是什么，其含义是什么，导致相互使用的原因，情况或最佳实践是什么。 副作用之一当然是速度（+1 Rob）。我最感兴趣的是在功能方面选择一个而不是另一个的实际原因。

11 design-patterns  coding-style  html  css 

我正在阅读“ C ++编码标准”，并且此行在其中： 变量会引入状态，因此您必须处理尽可能少的状态，并且生存期应尽可能短。 最终变异的所有东西都不会操纵状态吗？什么是你应该有应对尽可能少的状态尽可能的意思吗？ 在不纯正的语言（例如C ++）中，状态管理不是您真正在做什么吗？除了限制可变寿命之外，还有什么其他方法可以处理尽可能少的状态？

11 c++  coding-style  programming-languages  state 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 使用Python或Javascript时，应始终将二进制运算符放在上一行的末尾，以防止换行符过早地终止代码。它可以帮助您发现错误。 但是在C或C ++中，这不是问题，所以我想知道： 我有什么理由比第二个版本更喜欢第二个版本吗？ return lots_of_text + 1; 与 return lots_of_text + 1; （例如，其中之一有助于防止其他类型的错误吗？还是其中之一被认为更具可读性？）

11 c++  coding-style 

我今天在和一位同事聊天。我们为两个不同的项目编写代码。就我而言，我是唯一编写我的代码的人。在她的案例中，有多个人在同一代码库上工作，包括相当定期（每8-12个月之间）来来去去的合作学生。她说自己对自己的言论持开放态度，无处不在。她的理由是，它可以帮助她记住事情在哪里以及做什么，因为许多代码不是她编写的，并且可以由她以外的其他人更改。同时，我尝试将代码中的注释减至最少，仅将它们放在不明显的解决方法或错误的地方。但是，我对代码整体有了更好的了解，并且可以对其进行更直接的控制。 我的意见是，评论应尽量少，代码应能说明大多数情况，但她的推理也是有道理的。她的推理有什么缺陷吗？它可能会使代码混乱，但是如果有很多人在中短期内对其进行操作，则最终可能会很有帮助。

11 coding-style  team  comments 

这是一个相关的问题： 在返回不良样式/危险之后，使用finally子句进行工作吗？ 在引用的Q中，最终代码与所使用的结构和预取的必要性有关。我的问题有所不同，我认为这与广大受众密切相关。我的特定示例是C＃winform应用程序，但这同样适用于C ++ / Java。 我注意到很多try-catch-finally块，其中有很多与异常无关的代码以及埋在该块中的异常处理/清除。而且，我会偏向于使用非常紧密的try-catch-finally块，并将其代码与异常和处理紧密相关。这是我所看到的一些示例。 尝试块将设置许多初步调用和变量，从而导致可能引发的代码。日志信息将被设置并在try块中运行。 最后，块将具有表单/模块/控件格式化调用（尽管应用程序即将终止，如catch块所示），以及创建新对象（例如面板）。 大致： methodName（...） { 尝试 { //该方法的大量代码... //可能抛出的代码... //该方法还有更多代码和返回值... } 抓住（某物） {//处理异常} 最后 { //由于异常而进行一些清理，将事情关闭 //有关所创建内容的更多代码（忽略任何异常都可能引发）... //可能会创建更多对象 } } 该代码有效，因此具有一定的价值。它没有很好地封装，逻辑有点混乱。我（痛苦地）熟悉了代码移位和重构的风险，因此我的问题归结为想要了解其他人对类似结构的代码的经验。 不良的风格是否有理由进行更改？有没有人被类似的情况严重烧死？您是否愿意分享糟糕经历的细节？别说是因为我反应过度，风格还不错吗？获得整理事物的维护利益？

11 design  exception-handling  coding-style 

考虑以下示例： 我有一个网站。它允许用户发布帖子（可以是任何内容）并添加描述帖子的标签。在代码中，我有两个代表帖子和标签的类。让我们称这些类Post和Tag。 Post负责创建帖子，删除帖子，更新帖子等。 Tag负责创建标签，删除标签，更新标签等。 缺少一项操作。标签到帖子的链接。我正在努力与谁应该执行此操作。它在任何一个类别中都同样适用。 一方面，Post该类可以具有一个将a Tag作为参数的函数，然后将其存储在标签列表中。另一方面，Tag该类可以具有将a Post作为参数并将链接Tag到的函数Post。 以上只是我的问题的一个示例。实际上，我遇到了多个相似的类。两者都可以很好地融合在一起。除了实际上在两个类中都包含功能之外，还存在哪些约定或设计风格可以帮助我解决此问题。我假设必须要挑选一个呢？ 也许将它们放在两个类中都是正确的答案？

11 design  design-patterns  coding-style  single-responsibility 

我最近养成了一个习惯，我知道你们中的许多人可能会不习惯这种习惯，但是最终，这有助于我关注全局代码结构，而不是单个（有时）重复方法的结构：将数字分组单行中的语句，如下所示： textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!"; 相对于 textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!"; 在重复性任务中，我通常这样做，以保持整体代码“美观”并帮助我轻松地跟踪程序结构，但是我承认这可能不是一个好习惯。我实际上经常使用它，所以我想知道您对此有何想法。另外，您是否认为任何必须维护我的代码的人都对这种方法有疑问？

11 coding-style 

我想这个问题将立即被标记为主观的，但是您认为哪个更好： double volume(double pressure, double n_moles, double temperature) { return n_moles * BOLTZMANN_CONSTANT * temperature / pressure; } 要么 double volume(double P, double n, double T) { return n*R*T/P; } 换句话说，实现某些方程式的函数应该遵循该方程式的符号，还是应该使用更多详细的名称？

11 math  coding-style  readability 

有时您想从一个函数返回多个值。 这通常在Java中如何完成？ 一种选择是使用数组，例如返回列表或元组的Python代码段： value, success = read_unreliably() if success: print value 另一个选择是返回哈希/字典，如下面的JavaScript示例： var result = readUnreliably() if (result.success) { alert(value); } 还有一种方法就是为此目的创建一个自定义对象，例如以下Java示例： ReadUnreliablyResult result = readUnreliably() if (result.getSuccess()) { System.out.println(result.getValue()); } 当然，您也可以只使用一些全局变量来存储所需的内容，而不用传递东西，但是我们只能说这不是一种选择。

11 java  coding-style 

很久以前，我在ADA中编写了很多程序，调用函数时为参数命名是很正常的-SomeObject.DoSomething（SomeParameterName => someValue）; 既然C＃支持命名参数，我正在考虑在参数的含义可能不太明显的情况下恢复这种习惯。 您可能会争辩说参数的含义应该总是很明显，但是如果您具有布尔参数，并且调用者传递的是“ true”或“ false”，则用名称限定值可以使调用站点更具可读性。 contentFetcher.DownloadNote（note，manual：true）; 我想我可以创建枚举而不是使用true或false（在这种情况下为Manual，Automatic）。 您如何偶尔使用命名参数使代码更易于阅读？

11 coding-style 

Java 8添加了功能接口的概念，以及许多旨在采用功能接口的新方法。这些接口的实例可以使用方法引用表达式（例如SomeClass::someMethod）和lambda表达式（例如(x, y) -> x + y）来简洁地创建。 我和一位同事对什么时候最好使用一种或另一种形式（在这种情况下，“最佳”实际上可以归结为“最易读”和“最符合标准做法”）有不同的看法，因为他们基本上是相反的当量）。具体而言，这涉及以下所有情况： 所涉及的函数不在单个范围内使用 给实例起个名字有助于提高可读性（与之相反，例如，逻辑足够简单以一目了然地看到正在发生的事情） 没有其他编程原因可以解释为什么一种形式优于另一种形式。 我目前对此事的看法是，添加私有方法并通过方法引用进行引用是更好的方法。感觉这就是设计功能使用方式的方式，并且似乎更容易通过方法名称和签名传达正在发生的事情（例如，“ boolean isResultInFuture（Result result）”显然是在说要返回布尔值）。如果将来对类的增强希望使用相同的检查，但不需要功能接口包装器，则这也可使private方法可重用。 我的同事希望使用一种方法来返回接口的实例（例如“ Predicate resultInFuture（）”）。对我而言，这感觉不完全是该功能的预期用途，感觉有点笨拙，而且似乎很难通过命名来真正传达意图。 为了使这个示例具体，下面是使用不同样式编写的相同代码： public class ResultProcessor { public void doSomethingImportant(List<Result> results) { results.filter(this::isResultInFuture).forEach({ result -> // Do something important with each future result line }); } private boolean isResultInFuture(Result result) { someOtherService.getResultDateFromDatabase(result).after(new Date()); } …

11 java  coding-style  naming  methods  lambda