Questions tagged «programming-practices»

对于某些系统，时间值9999-12-31用作计算机可以计算的时间的“结束时间”。但是，如果改变了怎么办？将此时间定义为内置变量会更好吗？ 在C和其他编程语言中，通常使用诸如MAX_INT或类似的变量来获取整数可能具有的最大值。为什么没有类似的函数MAX_TIME将变量设置为“时间结束”，对于许多系统而言，该时间通常为9999-12-31。为了避免硬编码到错误的年份（9999）的问题，这些系统是否可以为“时间结束”引入变量？ **真实示例** End of validity date: 31/12/9999.（这样列出了正式文档）博客作者希望编写一个始终位于最上方的页面，即欢迎页面。因此，它有一个尽可能远的将来的日期： 3000？是的，您面临的欢迎页面发布于3000年1月1日。因此，该页面将永远保留在博客的顶部=）它实际上发布于2007年8月31日。

12 programming-practices  time  date-format 

我正在尝试提出一个个人工作流程。我整理了一个发行版的假设生命周期的流程图：一个开发人员推向公开的github repo +一个帮助提供某些功能并修复bug的朋友。 这是版本控制的合理方法吗？ 主要思想是保持公共仓库整洁： 每个新版本都会进入自己的分支，直到完成后最终在master分支中对其进行标记。 为了防止异常，所有工作都在“功能”或“修补程序”分支上进行，而不是在实际的发行分支上进行。 合并到更高级别的分支总是要重新设置基础或进行压缩（以避免混乱）。 如果这太过猛烈，我不介意，因为对我而言，重点就在于学习大型项目可能需要的技能。唯一的问题是，如果我在做完全错误或不必要的事情。 编辑2：修正原始流程图中的错误主意，并使它更易于浏览。

12 project-management  programming-practices  version-control  git  workflows 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 5年前关闭。 我认为程序的两个主要问题是代码结构/组织和错误处理。我正在阅读Code Complete 2，但是我需要阅读一些有关潜在问题的书籍。 例如，在一个网站上，如果仅当用户通过javascript篡改数据时才有可能发生某些事情，您是否为此写信？另外，什么时候不捕获错误？当您编写一个期望一个字符串和一个int作为输入的类，而它们不是一个字符串和int时，您是否进行检查，还是让它冒泡到传递了错误参数的调用方法？ 我知道这是一个广泛的主题，在这里不能一口气回答，所以我要寻找的是一本通常被教为教授适当的异常处理实践的书或资源。

12 programming-practices  books  exceptions  exception-handling 

在游戏开发中，商业应用程序C＃中有很多C / C ++。我已经看到C / C ++开发人员对单行代码如何转换为汇编表达了担忧。在.NET中，很少有人进入IL。 在C＃中，“微优化”被皱眉了，很少见并且通常是浪费时间。在游戏开发中似乎并非如此。 是什么造成了这种不一致？游戏会不断推动硬件极限吗？如果可以，随着硬件的改进，我们是否应该期望高级语言接管游戏产业？ 我不是想就C＃作为游戏开发者的可行性进行辩论。我知道它已经完成了一定程度。专注于微优化。具体来说，Game Dev与Applications dev之间的区别。 游戏更新我的意思是现代，大规模的发展。EG MMORPG，Xbox，PS3，Wii ...

12 programming-practices 

是否有太多的统一性？在我工作的地方，我们当然有一些标准，包括命名约定，体系结构，可利用的框架等。但是最近，我认为应该更多地考虑样式的事情很多。 例如if，使用c＃??null-coalescing运算符而不是say == null，在多行对一行中编写语句，而不是缩进间隔等。 在我看来，这开始越来越多地成为个人风格的选择，而不必在团队或公司中保持统一。一个人的想法可能更清楚地阅读了另一个人。这种“额外”的均匀性是否有价值？

12 programming-practices  team  coding-standards 

我们正在构建一个Web服务（SOAP，.Net），该服务将与（大多数）本地客户端（Windows，C ++）进行通信，并且我们想知道将错误传达给客户端的最佳方法是什么（例如，不提供登录服务的SomethingBadHappened或类似未找到用户的内容），并且无法决定是向客户端抛出异常还是使用某种错误代码模型来执行上述操作。 您希望在客户端上进行处理的是：接收错误代码或处理包含错误原因的ServerFault异常？ 1）我们为什么想例外：因为它将使服务器端代码有很多更均匀 2）为什么我们都在思考错误代码：因为我们认为它使从客户端的角度更有意义。 如果2）确实是真的，我们可能会想使用错误代码而不是异常代码？是这样吗？ 另外，如果我们与托管客户而不是本地客户进行交谈，答案是否会改变？

12 programming-practices  exceptions  error-handling 

如果您正在招聘程序员，并且可以选择（例如）topcoder.com上排名前100的编码器之一，或者stackoverflow.com上排名前100的编码器之一，那么您会选择哪种呢？ 至少在我看来，topcoder.com似乎对解决问题和编写代码的纯粹能力给出了更为客观的评估。同时，尽管具有明显的技术能力，但此人可能缺乏任何社交技巧的提示-他可能纯粹是“孤独的编码者”，几乎没有或根本没有帮助/与他人合作的能力，可能缺乏指导他人转移能力的指导能力他对他人的技术能力等 另一方面，stackoverflow.com似乎至少可以更好地表明同行对所讨论编码员的看法，以及他的存在和在“团队”中对其他人有用和有帮助的程度。同时，计分系统是这样的，一个仅仅抛出很多平庸（甚至答案很差）的人几乎不可避免地会积a正数的“声誉”点-一次投票（也许只是出于（礼貌）将抵消不少于5次的否决投票的影响，并且（在某种程度上）不鼓励其他人进行否决投票，因为这样做必须牺牲自己的声誉。同时，可以说，几乎没有什么技术贡献或没有技术贡献的人似乎不太可能积累声誉，从而使他们（甚至接近）占据顶峰。 那么，哪一种方法可以提供更有用的指示，说明该特定编码员在多大程度上对您的组织有用？如果您可以在他们之间进行选择，那么您希望与哪一组编码员一起工作？

12 programming-practices  team 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我在很多地方Resolve都使用过这个词，例如在“依赖注入”（解析接口的实现），“包管理器”（例如：解析包的依赖关系），“ Web”（例如：解析主机名）中。 那么，是什么使代码的逻辑，特别是使一个人选择这个词Resolve在简单的Convert或者Transform甚至是Get？

12 programming-practices  naming  dependency-injection  packages 

从高中开始我就被教导要定义如下变量： int _a; 要么 int __a; 应该将其视为不良做法，因为这最终会使使用下划线开头的变量来命名临时变量的编译器感到困惑。 据我所知，这就是有些人喜欢在名称末尾移动下划线的原因，例如： int a_; 但是，我看到很多代码都使用下划线开头的变量。而且该代码在Visual Studio 2010和g ++ 4.x中都可以很好地构建。 所以我想知道：这今天不是问题吗？现代编译器在命名约定方面更聪明吗？

12 c++  programming-practices  naming-standards 

我是一个有抱负的游戏开发人员，我偶尔从事独立游戏的工作，有一段时间我一开始似乎做不好，但是我真的想从这里的一些经验丰富的程序员那里得到答案。 假设我有一个名为的文件enumList.h，其中声明了我想在游戏中使用的所有枚举： // enumList.h enum materials_t { WOOD, STONE, ETC }; enum entity_t { PLAYER, MONSTER }; enum map_t { 2D, 3D }; // and so on. // Tile.h #include "enumList.h" #include <vector> class tile { // stuff }; 主要思想是，我在1个文件中声明游戏中的所有枚举，然后在需要使用某个枚举时将其导入，而不是在需要使用的文件中声明该枚举。我这样做是因为它使事情变得干净，我可以在一个地方访问每个枚举，而不必只打开页面来访问一个枚举。 这是不好的做法吗？它会以任何方式影响性能吗？

12 c++  programming-practices  enum 

我最近正在阅读一个有关干净代码开发的网站（我不在此处放置链接，因为它不是英语）。 本网站宣传的原则之一是开放式封闭原则：每个软件组件都应开放以进行扩展，而封闭则可以进行修改。例如，当我们实现并测试了一个类时，我们仅应对其进行修改以修复错误或添加新功能（例如，不影响现有方法的新方法）。现有功能和实现不应更改。 我通常通过定义接口I和相应的实现类来应用此原理A。当类A变得稳定（实现并经过测试）后，我通常不会对其进行过多修改（可能根本没有修改），即 如果新的要求到达需要的代码大的变化（如性能，还是一个全新的接口的实现），我写了一个新的实现B，并使用保持A，只要B还没有成熟。当B成熟时，所需要做的就是更改I实例化方式。 如果新的要求也建议更改接口，那么我将定义一个新的接口I'和一个新的实现A'。所以I，A被冻结并保持实施生产系统，只要I'和A'不够稳定，以取代他们。 因此，鉴于这些观察，令我感到惊讶的是该网页随后建议使用复杂的重构，“……因为不可能直接以其最终形式编写代码。” 在执行“开放/封闭原则”与建议使用复杂重构作为最佳实践之间是否存在矛盾/冲突？还是这里的想法是，在开发一个类的过程中可以使用复杂的重构A，但是当成功测试了该类后，应该冻结它吗？

12 programming-practices  refactoring  open-close 

我正在开发Java 6 EE应用程序，并且正在用另一版本的jsp代码测试我的jsp代码，该版本具有测试版本的函数调用和原始版本中使用的代码，但它看起来松散且不切实际。有没有一种好的方法来完成这种测试？

12 testing  programming-practices  unit-testing  java-ee 

我的一个朋友告诉我，最佳实践是main应命名Main包含main方法的类，而只包含方法。此外main方法应该只解析输入，创建其他对象和调用其他方法。本Main类和main方法，不应该做任何事情。基本上他在说包含main方法的类应该是这样的： public class Main { public static void main(String[] args) { //parse inputs //create other objects //call methods } } 这是最佳做法吗？

12 object-oriented  programming-practices 

当我尝试为特定程序创建接口时，通常是在尝试避免引发依赖于未经验证的输入的异常。 因此，经常发生的事情是我想到了这样的一段代码（出于示例目的，这只是一个示例，不要介意它执行的功能，例如Java）： public static String padToEvenOriginal(int evenSize, String string) { if (evenSize % 2 == 1) { throw new IllegalArgumentException("evenSize argument is not even"); } if (string.length() >= evenSize) { return string; } StringBuilder sb = new StringBuilder(evenSize); sb.append(string); for (int i = string.length(); i < evenSize; i++) { sb.append(' …

11 design  design-patterns  programming-practices  performance  validation 

我们正在进行一个新项目，目前开发人员已分为两个团队，即团队A和团队B。该项目有两个部分，需要在整个开发堆栈中进行开发。堆栈的简化示例如下所示： 项目的每个部分都需要在整个堆栈上进行开发，因此我通常希望使用完整的堆栈开发人员方法，这就是我们如何分解团队B中的工作，设计和设计不同部分之间的交互的方式。 但是，我最近了解到，团队A要负责堆栈的某些部分，他们提议在两个团队之间进行划分，其中数据抽象层（并将内容放入数据层）由团队B没有任何发展。这种鸿沟看起来类似于： 对我来说，这感觉很不自然。每个团队都有不同的目标和时间表来实现这些目标，但是B团队将依赖于A团队来实现功能。提出的解决方案是预先定义通用接口（该项目可能需要2年的时间，因此可能会很多）。尽管有自己的目标，团队A仍将尽早为这些接口开发所需的位，而团队B则在短期内取消所有呼叫，以便他们继续前进。 我对此方法感到担忧： 接口可能会更改，并且组A可能没有带宽或时间来适应不断变化的需求。 A团队代码中的错误可能会阻止B团队前进，并且由于A团队的优先级队列不同，它们可能也不是解决这些错误的优先事项。 团队之间缺乏知识传播-团队B可能无法完全了解幕后情况，因此可能会做出糟糕的设计决策。 已经提出，该行业中的许多公司都有子团队，并且必须能够处理此问题。根据我的理解，通常团队会按照最初的期望进行拆分（全栈），或者通过如下分解技术栈： 因此，我有兴趣了解其他行业的情况。大多数拆分是垂直/水平的吗？对角线分割有意义吗？如果发生对角线分裂，我的担忧似乎是成立的，并且B团队还有其他需要关注的问题吗？请注意，我可能要对B团队的成功或失败负责。

11 architecture  programming-practices  development-process  team