15

我花了两周时间试图计算基于变量的东西。

事实证明，我之前设置了变量是为了暂时解决另一个问题，并且再也没有回去纠正它。

通常，我尝试用 //ToDo 标记代码以提醒我删除临时变量。

在这种情况下，我没有标记它，因为我正在跳过尝试修复多个问题。（我不知道发生了什么，所以我尝试了各种各样的东西！）

您如何标记您希望稍后删除的临时变量？

  1. 您是否在班级顶部将它们实例化为私有？
  2. 用类似 //Delete Me Later 之类的东西将它们标记为内联

标记以后需要删除的变量的最佳做法是什么？

（当然，没有一个真正有组织的大脑......）

4

8 回答 8

36

使用注释@Deprecated

@Deprecated
public void Test() {
  //
}
于 2012-08-10T12:52:58.990 回答
14

经过一番谷歌搜索后找到了它，因为我也很好奇。

@Deprecated
public void speak() {
   System.out.println("Meow."); 
}

来自维基百科，关于Java 注释：

Java 定义了一组内置于语言中的注解。应用于 java 代码的注释：@Override - 检查该函数是否为覆盖。如果在其中一个父类中找不到该函数，则会导致编译警告。@Deprecated - 将函数标记为已过时。如果使用该函数，则会导致编译警告。@SuppressWarnings - 指示编译器抑制注解参数中指定的编译时警告 应用于其他注解的注解：@Retention - 指定标记注解的存储方式——无论是仅在代码中，编译到类中，还是在运行时通过反射可用. @Documented - 标记另一个注释以包含在文档中。

于 2012-08-10T12:52:54.640 回答
5

最佳实践是使用版本控制。一旦你修复了一个错误，你可以 git/hg/svn diff 来检查你自上次提交以来所做的事情并删除任何临时更改。如果您需要修复其他错误，但在多次提交中保留“临时更改”，您可以进行部分提交（git add --patch 或 hg qrecord），这样您的“临时更改”就不会被提交和遗忘。对于非常大的临时代码（不是最佳实践，但它可能会发生），您可以创建一个本地分支，您可以在正常代码的基础上继续对其进行变基。一旦您确定要删除“临时更改”，您就可以简单地清理所有未提交的更改，然后测试问题。

于 2012-08-10T12:55:41.653 回答
4

本地分支（git，搁置 IntelliJ 中的更改，在本地签出两个源副本），因此当您从一项任务转移到另一项任务时，而不是仅仅处理部分完成的工作，您创建第二个分支并不要'在完成之前不要提交/推送第一个。

成对提交/推送 - 所以在你与第二个人讨论代码之前不要提交，第二个人会指向临时代码块并询问你。希望能强迫你在提交之前解决该死的问题。

不要使用 TODO 或其他此类评论，因为它们永远不会被执行。

如果它已经是公开的并且正在外部使用，那么 @Deprecate 它。

于 2012-08-10T13:03:28.860 回答
0

首先，我在每个变量名称前加上“TODO_REMOVE_”或类似名称。这样，如果我忘记删除它并且后来有人遇到它，很明显应该删除该变量。此外，如果我执行下面的最后一步，我将始终在签入之前将其删除。

接下来，我向它添加一个 TODO 注释并用 Deprecated 对其进行注释。我知道其他人说过 TODO 永远不会被执行，但是当我提交时，我的 IDE（在本例中为 IntelliJ）警告我有 X 个 TODO 正在提交。如果您在办理登机手续时收到类似的消息，那应该会在您的脑海中留下一个标志。此外，如果您发现自己经常这样做，请制作一个实时模板、片段或您的 IDE 提供的任何其他内容，这样您只需键入类类型和变量名。

@Deprecated
Object TODO_REMOVE_variableName;//TODO Remove

最后，在检查更改集之前，我会尝试重新阅读、理解、改进和确认我编写的每一行代码。这很重要！我知道一开始这听起来可能令人生畏，尤其是对于大的更改或当你有迫在眉睫的最后期限时，但与你编写代码所花费的时间、它揭示的问题和未来的时间相比，这只是杯水车薪它节省是非常值得的。真的，我希望每个开发人员都这样做。

于 2012-08-10T14:37:16.353 回答
0

如果您使用的是 Eclipse，我建议您使用

有一个新的任务标签，比如“删除”，它可以帮助您轻松识别需要删除哪些临时代码。将优先级设置为高。

打开任务视图以检查 REMOVE 任务并采取措施。

请通过以下链接（也提供了 UI 屏幕截图）

StackOverflow 关于任务标签的问答

于 2012-08-10T17:45:55.187 回答
0

我没有对每一个想法/建议发表评论，而是想我会回答，然后让你对这个答案投票。

首先，非常感谢您分享您的流程和想法。对此，我真的非常感激。

我认为有许多因素应该由避免犯愚蠢错误或遭受你已经犯过的错误的愿望驱动。我做了一个（许多。）

让我们假设版本控制和团队审查胜过一切；但是超出了版本控制（假设您将 crappola 提交给您的好代码）：

  • @Deprecated 非常好。它似乎在瞪着你。我们都需要耀眼。希望我们能透过树木看到森林。

  • 对我来说，差异是繁重的，因为我经常进行彻底的更改，但这是一个在许多情况下都有效的好建议。

一些值得注意的事情：

因为我通常是唯一的开发者，所以我依赖 ToDos。它们易于使用。我对待办事项有一个非正式的评级系统。例如，真正需要清理的东西是这样的：

//TODO * Might be a future crash here // where one star is something I really have to clean up before I ship. 
//TODO *** Can some lines be trimmed from this view adapter?

多颗星是任意的，甚至可能是可选的。我不断地骑自行车穿过它们。@ BriGuy37 - 这是一个有趣的想法。@Sriram - 这也很有趣 - 在某些条件下设置标签。

就我而言，我没有删除//TODO，它让我很伤心。

所有这一切中最大的规则可能是：

以一种不会犯这种愚蠢错误的方式统一你的工作。了解您正在做出哪些改变以及何时做出改变。保持冷静。

再次感谢！很高兴从社区中汲取最佳实践并融入您的工作！

于 2012-08-12T14:50:17.583 回答
0

如果您使用的是 SVN* 并且您所做的更改应该在提交更改之前修复（例如，用于本地调试/测试的临时更改），您可以添加评论// STOP-COMMIT并设置预提交挂钩禁止提交任何包含此文本的文件。

这也适用于标记不应提交给 SVN 的配置文件的本地更改。

如果您的 IDE 支持为给定字符串搜索注释的 TODO 列表，您甚至可以创建自定义 TODO 格式来查找该字符串。

* 我猜你可以对许多其他版本控制系统做类似的事情

于 2012-08-13T20:27:50.120 回答