Questions tagged «programming-practices»

我一直在研究一些算法，并一直在研究SPOJ.pl TopCoder等网站。我发现程序员通常在大多数算法编程竞赛中都喜欢C或C ++。 现在，我最近遇到了一些麻烦。我对C和Python都了解一些，并且在尝试编写代码时，对于大多数算法，我似乎更喜欢Python而不是C。每当我坐下来写CI的代码时，大约15分钟后就放弃了，因为我觉得它太麻烦了并且倾向于使用python。传递矩阵指针等似乎浪费了我实际上可以用来思考算法本身的时间。 现在，我知道并且听到很多人说C是一种非常重要的语言，并且是许多程序员的后援。 我想知道的是，我的这种方法是否有任何缺点/后果/缺点等。 这不是Python与C的争论。从长远来看，这个关于易用性而不是C首选python的特定实践将如何影响我或任何其他程序员/计算机科学家的问题。 我很乐意听到在行业中使用过这些语言的人，以及/或者开发大型软件/库等的人。

16 algorithms  python  c  programming-practices  self-improvement 

单个通用应用程序可以做些什么来影响其运行设备的功耗吗？ 我不熟悉对单个应用程序进行的优化如何以一般方式影响功耗，有人可以解释一下编写应用程序的不同方法是否会影响所运行设备的功耗？ 也就是说，可以以不同的方式编写的功能上完全相同的单一程序是否会在总体上极大地影响设备的功耗，而与不同的无关程序可能如何影响设备的功耗无关。

16 programming-practices  optimization  multi-platform 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 我曾经在8到10年前广泛地编写C ++。从那以后，出于专业原因，我开始使用C＃。但是，我有时会看到类似 “如果您仍在手动跟踪指针引用，那么您做错了” 要么 “只要您使用的是RAII之类的现代概念，并且不像正在恢复的C开发人员那样手动分配内存，C ++绝对是安全的。” 两者都是十年前的标准程序。我已经看到，最近C ++有了很大的改进。特别是C ++ 0x似乎具有一些新功能。对于“ C / old C ++”程序员来说，赶上“现代” C ++模式和实践的最佳资源是什么？

16 c++  design-patterns  c  programming-practices  c++11 

有人可以解释编程中对模式和反模式的痴迷吗？我问是因为我完全不知道任何模式的含义。面对编程任务时，我会稍微考虑一下该问题，写下一些我认为相关的数据结构，为解决方案提供原型，分离出一些模块并进行迭代。在此过程中，我认为“哦，我这里需要FunkyLookyTastic模式”无处不在。

16 programming-practices  design-patterns  anti-patterns 

考虑： public class CtorInjectionExample { public CtorInjectionExample(ISomeRepository SomeRepositoryIn, IOtherRepository OtherRepositoryIn) { this._someRepository = SomeRepositoryIn; this._otherRepository = OtherRepositoryIn; } public void SomeMethod() { //use this._someRepository } public void OtherMethod() { //use this._otherRepository } } 反对： public class MethodInjectionExample { public MethodInjectionExample() { } public void SomeMethod(ISomeRepository SomeRepositoryIn) { //use SomeRepositoryIn } …

16 design-patterns  programming-practices  dependency-injection  patterns-and-practices 

在查看新的代码库时，我喜欢从下至上的方法开始。 我在其中理解一个文件，然后移至下一个抽象。 但是很多时候我发现自己忘记了底层抽象在做什么。 因此，在这一点上，我发现自己陷入了无尽的循环，回到我以前完全理解的文件，然后尝试重新学习它们。同时尝试弄乱彼此之间相互联系的许多其他抽象。 是否有更好的策略来应对这种情况？ 我是否应该忘记较低级别的细节，并将其视为既定知识？但是即使如此，很多时候仍需要对底层抽象有一个先前的了解，以了解当前抽象在做什么。

15 programming-practices  abstraction  strategy  low-level  high-level 

我想在很久以前编写的某些仍能正常工作的代码中进行一些增强，然后再以其编写的编程语言具有更多功能。从理论上讲，整个项目都使用该语言的最新版本。但是，该特定模块（实际上还有许多其他模块）仍然使用较旧的方言编写。 我是不是该： 不用接触我不需要接触的代码部分，而是利用新的语言功能编写我的补丁程序，这些新功能使编写补丁程序更加容易，但是在模块中其他任何地方都无法使用？（这是我直观选择的解决方案。） 忽略岁月流逝的事实，并在编写补丁时反映出代码其余部分中使用的样式，就像我早在多年前一样正在做同样的事情一样吗？（我直觉上认为这种解决方案很愚蠢，但是鉴于每个人都在谈论“好的代码”而大惊小怪，因此不惜一切代价保持一致性，也许这就是我应该做的。） 更新整个模块以使用较新的语言构造和约定？（这可能是最好的解决方案，但可能需要大量时间和精力，而最好将其花费在其他任务上。）

15 programming-practices  maintenance 

我在应用程序开发方面只有2年以上的经验。在那两年中，我对发展的态度如下 分析需求 身份核心组件/对象，必需功能，行为，过程及其约束 创建类，它们之间的关系，对象行为和状态的约束 根据要求创建功能，处理行为约束 手动测试应用 如果需求更改修改组件/功能，则手动测试应用程序 最近，我对TDD进行了介绍，并认为这是进行开发的好方法，因为已开发的代码有充分的理由存在，并且可以缓解许多后期部署问题。 但是我的问题是我不能先创建测试，而是要标识组件，并在实际编写组件之前为它们编写测试。我的问题是 我做对了吗？如果不是，我到底要改变什么 有什么方法可以确定您编写的测试是否足够？ 是针对非常简单的功能（相当于1 + 1 = 2）编写测试的好习惯吗？ 更改功能并相应地测试需求是否有所变化是否很好？

15 programming-practices  unit-testing  tdd  acceptance-testing 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我刚刚编写了一个跨越约100行的函数。听到这个消息，您可能很想告诉我有关单一责任的事，并敦促我进行重构。这也是我的直觉，但这是问题所在：函数做一件事。它执行复杂的字符串操作，并且函数主体主要由一个详细的正则表达式组成，分为许多行，并记录在案。如果我将正则表达式分解为多个功能，我会感觉实际上会失去可读性，因为我正在有效地切换语言，并且无法利用正则表达式提供的某些功能。现在是我的问题： 在使用正则表达式进行字符串操作时，大型函数体是否仍然是反模式？似乎命名捕获组的作用与功能非常相似。顺便说一下，我对通过正则表达式的每个流进行测试。

15 programming-practices  refactoring  anti-patterns  regular-expressions  single-responsibility 

我们的知识领域涉及人们赤脚行走在压力记录板上。如果在传感器数据中识别出人脚，我们会进行图像识别，从而产生“脚”类对象。 必须对脚的数据执行一些计算。 现在，哪种API更好： class Foot : public RecognizedObject { MaxPressureFrame getMaxPressureFrame(); FootAxis getFootAxis(); AnatomicalZones getAnatomicalZones(); // + similar getters for other calculations // ... } 要么： class Foot : public RecognizedObject { virtual CalculationBase getCalculation(QString aName); // ... } 现在，我可以提出很多优点和缺点，但是我不能真正决定哪个最重要。请注意，这是最终用户应用程序，而不是我们出售的软件库。 有什么建议吗？ 第一种方法的一些专家可能是： 吻-一切都非常具体。API，但实施也是如此。 强类型返回值。 从此类继承是万无一失的。什么都不能覆盖，只能添加。 API是非常封闭的，什么都不会进入，什么都不能被覆盖，所以更少的地方会出错。 一些缺点： 随着我们发明的每一项新计算都被添加到列表中，吸气剂的数量将会增加 API更可能会更改，如果引入了重大更改，我们需要一个新的API版本，即Foot2。 如果在其他项目中重复使用该类，我们可能不需要进行所有计算 …

15 design  c++  object-oriented  programming-practices  language-agnostic 

我有一种情况，我的父母知道这是孩子（duh），但我希望孩子能够引用父母。原因是我希望孩子有能力在感觉到自己时将自己指定为最重要或最不重要。当孩子这样做时，它将移动到父母孩子的顶部或底部。 过去，我曾在孩子身上使用WeakReference属性来引用其父对象，但我觉得这增加了一个烦人的开销，但这也许是最好的方法。 这只是一个坏主意吗？您将如何以不同方式实施此功能？ 更新1：添加更多上下文。这是一个渲染系统，因此父容器是组合在一起的窗口列表。子项（窗口）说“我最重要！” 希望基本上呈现在其余窗口的顶部。 父母只是将这些孩子分组在一起的逻辑容器。我可以看到在哪里添加事件以表明请求位于顶部是一个好主意。但是除了实现（孩子想与父母做什么）之外，为什么不希望有child-> parent链接？双向链接列表可以做到这一点，这样人们就可以遍历某物。

15 c#  programming-practices 

一方面，有一条建议说“建一个要扔掉”。只有在完成软件系统并查看最终产品之后，我们才能意识到设计阶段出了什么问题，并了解我们应该如何真正做到这一点。 另一方面，存在“第二系统效应”，它表示设计的同一类型的第二系统通常比第一个系统差。有许多功能不适合第一个项目，而被推入第二个版本通常会导致过于复杂和过度设计。 这些原则之间不是在这里有些矛盾吗？对这些问题的正确看法是什么，两者之间的边界在哪里？ 我认为，这些“好的做法”是在弗雷德·布鲁克斯（Fred Brooks）的开创性著作《神话人月》中首次得到推广的。 我知道其中一些问题已通过敏捷方法解决，但从深处看，问题仍然是原则。例如，在上线之前，我们不会对3个Sprint进行重要的设计更改。

15 design  project-management  programming-practices  project  principles 

假设程序员是作者，并且编写代码来表达抽象的思想和概念，并且其他程序员应该阅读良好的代码而没有困难和误解，那么程序员是否应该参加写作课程来编写更好的代码？ 抽象概念和现实世界中的问题/实体是编写优质代码的重要组成部分，并且对编码语言的良好掌握应该可以使程序员更轻松或以更好的方式表达自己的想法。此外，在尝试编写或重写某些代码以使其更好时，可以花很多时间来确定函数，变量或数据结构的名称。 我认为这也可以避免编写具有多种含义的代码，这通常会导致不同程序员之间的误解。代码应始终明确表达其功能。

15 programming-practices  coding-style  code-quality 

如果相关程序正常运行，返回非零退出代码是否可以接受？例如，假设我有一个简单的程序（仅）执行以下操作： 程序接受N个参数。它返回退出代码min（N，255）。请注意，任何N对该程序均有效。 一个更现实的程序可能会返回不同的代码，以成功运行表示不同事物的程序。这些程序是否应该将该信息写到流中，例如stdout？

15 programming-practices  exit-strategy 

我一直在印象中，monkeypatching属于快速和肮脏的hack类别，而不是标准的良好编程习惯。虽然我不时使用修复第三方库的小问题，但我认为这是临时性的修复，因此我会向第三方项目提交适当的补丁程序。 但是，我已经将该技术用作主流项目中的“常规方法”，例如在Gevent的gevent.monkey模块中。 Monkeypatching是否已成为主流，正常且可接受的编程实践？ 另请参阅：杰夫·阿特伍德（Jeff Atwood）的“ Monkeypatching for Humans”

15 python  programming-practices  ruby  meta-programming  monkey-patch