您是否签入了没有立即应用的新代码?

发布于 2024-10-01 05:39:52 字数 260 浏览 3 评论 0原文

在解决更大问题的过程中,我编写了一个新的类方法来计算该类对象的属性。我参考了标准,找到了适当的内部库调用来为我完成一些工作,我对其进行了充分注释,并将其应用于各种示例对象以验证结果。

后来我意识到我可以用完全不同的方式解决更大的问题。我根本不需要调用我的新方法。该函数可能对解决未来的某些问题有用,但如果我今天签入它,它将立即成为死代码。我用它做什么?检查一下吗?签入但 #ifdef 退出?将其签入并立即进行另一次提交以将其删除?把它留在 git-stash 中吗?接受损失并继续前进吗?

In the process of solving a larger problem I wrote a new class method to compute a property of objects of that class. I referred to standards, I found the appropriate internal library calls to do some of the work for me, I commented it fully and I applied it to a variety of sample objects to validate the results.

Later I realized I could solve the larger problem in an entirely different way. I would not need to call my new method at all. The function might be useful for solving some future problem, but if I check it in today it will immediately be dead code. What do I do with it? Check it in? Check it in but #ifdef'd out? Check it in and immediately make another commit to remove it? Leave it in a git-stash? Just accept the loss and move on?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

不即不离 2024-10-08 05:39:52

如果这是您的个人开发人员分支,请签入并标记它。确保您不会将其合并到您正在处理的任何功能或版本分支中。我有一个文件夹,我设置了 svn:ignore 属性,可以防止我意外地将此类内容添加回主分支中。

If this is your personal developer branch check it in and tag it. Make sure you don't merge it into whichever feature or version branch you are working on. I have a folder that I have an svn:ignore property set that prevents me accidentally adding this kind of stuff back into a main branch.

昨迟人 2024-10-08 05:39:52

不要签入生产树中的死代码。如果您认为将来有一天您可能会用到该代码,请将其签入您的个人存储库。

产品树中的任何内容都有相关的成本 - 代码审查、测试覆盖率、设计文档、公共 API 描述、线程建模、维护等。为未使用的代码支付费用意味着您在为用户提供的实际功能上的支出会减少。

Don't check in dead code in the production tree. If you think you might have some use for that code some day in the future, check it in to your personal repository.

Anything that is in the product tree has an associated cost - code review, test coverage, design doc, public API description, thread modeling, maintenance, and so on. Paying that cost for code that is not used means you have less to spend on actual features for your users.

枫林﹌晚霞¤ 2024-10-08 05:39:52

这完全取决于您和您公司的政策(如果适用)。

首先我想说这不是损失,你应该始终将其备用解决方案保留在某个地方,因为有一天你会想“嘿,这看起来像之前的问题......我是怎么做到的”,所以如果你有一个工作代码保留吧。

那么我不建议将其保留#ifdef或将其保留在工作代码中,因为当其他人阅读使用您的代码时,这将使他们更难遵循您的程序流程。 (在我的工作中,我们有一些跨桌面、DS、PSP 等编译的项目,当您必须使用多个 #define 阅读代码时,这很困难:没有必要让它变得更难:P。

提交的问题为我在开始时提到取决于你的情况,如果有其他人,那么问问自己这个代码是否有用,

希望它对

杰森有帮助。

This in entirely up to you and (if it applies) the policy in your company.

first I would say it is not a loss and you should always keep it alternated solution somewhere because you'll one day think "hey this looks like that previous problem... dam how did I do it", so if you have a working code keep it.

then I wouldn't advise leaving it #ifdef or leaving it inside working code because when somebody else reads use your code, it will make it harder for them to follow the flow of your program. (at my work we have some projects which are compiled across desktop, DS, PSP etc. and when you have to read the code with multiple #define its hard: There is no need to make it harder :P.

the question of submitting as I mentioned in the beginning depends on your situation. If you are alone on the project why not. if there are other people, then ask yourself if this code could be useful to then or not.

hope it helps

Jason

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文