签入“注释掉”码 [英] Checking in of "commented out" code

问题描述

好的，这里是一些东西，在我当前的工作，导致一些摩擦，我真的没想到它。组织内部软件开发是一个新的概念，我已经起草了一些编码指南的第一稿。

Ok, here is something that has caused some friction at my current job and I really didn't expect it to. Organized in house software development is a new concept here and I have drawn up a first draft of some coding guidelines.

我建议注释掉的代码永远不应该检入存储库。我说的这个原因是，存储库维护文件的完整历史。如果要删除功能代码，请将其全部删除。

I have proposed that "commented out" code should never be checked into the repository. The reason I have stated this is that the repository maintains a full history of the files. If you are removing the functional code then remove it altogether. The repository keeps your changes so it is easy to see what was changed.

这导致了一些摩擦，因为另一个开发人员认为采取这个路由太限制了。这个开发人员想要能够注释掉一些他正在工作但不完整的代码。这个代码然后永远不会被检查过，然后不保存在任何地方。我们将要使用TFS，所以我建议搁置更改将是最正确的解决方案。然而，它不被接受，因为他想要能够检查可能或可能不被部署的部分更改。

This has caused some friction in that another developer believes that taking this route is too restrictive. This developer would like to be able to comment out some code that he is working on but is incomplete. This code then would never have been checked in before and then not saved anywhere. We are going to be using TFS so I suggested that shelving the changes would be the most correct solution. It was not accepted however because he would like to be able to checkin partial changes that may or may not be deployed.

我们希望最终达到一个点，我们充分利用持续集成并自动部署到开发Web服务器。目前没有开发版本的网络服务器或数据库服务器，但这一切都将很快改变。

We want to eventually get to a point where we are taking full advantage of Continuous Integration and automatically deploying to a development web server. Currently there is no development version of web servers or database servers but that will all be changed soon.

无论如何，你的想法是什么？

Anyway, what are your thoughts? Do you believe that "commented out" code is useful to have in the repository?

我很感兴趣听听别人对这个主题的看法。

I'm very interested to hear from others on this topic.

编辑：
为了清楚起见，我们不使用私人分支。如果我们这样做，我会说，你想用你的私人分支，但不要用中继线或任何共享分支合并注释掉的代码。

For clarity sake, we don't use private branches. If we did then I'd say do what you want with your private branch but don't ever merge commented out code with the trunk or any shared branches.

编辑：
没有有效的理由，我们不使用私人或每个用户分支。这不是我不同意的概念。我们只是还没有设置它。也许这是最终的中间地带。现在我们使用TFS shelving。

There is no valid reason we don't use private or per user branches. It's not a concept I disagree with. We just haven't set it up that way yet. Perhaps that is the eventual middle ground. For now we use TFS shelving.

推荐答案

可能有其他人有不同的经验，但在我的检查半成品代码是一个可怕的想法，期间。

There may be others with different experiences, but in mine checking in half-finished code is a horrible idea, period.

以下是我学到并尝试遵循的原则：

Here are the principles I have learned and try to follow:

$ b

• 如果第一个和第二个第二个冲突（例如，使功能工作需要一天以上），那么任务过大 - 将其分解为更小的可完成任务。

• Check in often - at least once, but preferably many times per day
• Only check in complete functionality
• If the first and second conflict (e.g. it takes more than a day to make the functionality work) then the task is too large - break it into smaller completable tasks.

这意味着：

• 注释掉的代码不应该被检入，因为它不起作用


• 评论不是有效的档案策略，因此无论是尚未完成的代码还是即将退役的代码，评论和签入都没有任何意义。

所以总而言之，NO！如果代码还没有准备好进入下一个阶段（无论是适合你的：IntTest / QA / UAT / PreProd / Prod），它不应该被提交到中继或多开发人员分支。

So in summary, NO! If the code is not ready to go to the next stage (whichever that is for you: IntTest/QA/UAT/PreProd/Prod), it should not be committed to a trunk or multi-developer branch. Period.

编辑：阅读其他答案和评论后，我想补充说，我认为这不一定是一个好主意禁止注释代码（不知道你如何强制执行）。我会说的是，你应该让你的团队中的每个人都买进我上面描述的哲学。我工作的团队全心全意地拥抱它。因此，源代码管理是一个无关的团队成员，可以帮助我们完成工作。

After reading the other answers and comments, I'll add that I don't think it's necessarily a good idea to ban commented code (not sure how you'd enforce that anyway). What I will say is that you should get everyone on your team to buy in to the philosophy I described above. The team I work on embraces it wholeheartedly. As a result, source control is a frictonless team-member, one that helps us get our job done.

不接受哲学的人通常会导致损坏的窗口并且经常受到源控制的挫败。他们认为这是一个必要的邪恶，最好的东西，以避免在最坏的情况下;这导致不频繁的检查，这意味着变更集是巨大的，很难合并，这使复杂的挫折，使签到什么，避免更多，这是最终是一个态度的东西，不是一个真正的过程的东西。容易对其施加精神障碍;它很容易找到原因，为什么它不工作，就像很容易找到原因不节食，如果你不想真的想。但是，当人们想做这件事，并致力于改变他们的习惯，结果是戏剧性的。你有责任有效地销售它。

People who don't embrace that philosophy usually cause broken windows and are often frustrated by source control. They see it as a necessary evil at best, and something to avoid at worst; which leads to infrequent checkins, which means changesets are huge and hard to merge, which compounds frustration, makes checkins something to avoid even more, etc. This is ultimately an attitude thing, not really a process thing. It's easy to put up mental barriers against it; it's easy to find reasons why it won't work, just like it's easy to find reasons not to diet if you don't really want to. But when people do want to do it and are committed to changing their habits, the results are dramatic. The burden is on you to sell it effectively.

这篇关于签入“注释掉”码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！