删除变量java_标记需要稍后在Java中删除的变量的最佳实践是什么？

我ed了两个星期，试图计算基于变量的值。

事实证明，我较早设置了变量以临时解决另一个问题，但从未回过头来更正它。

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

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

如何标记要在以后删除的临时变量？

您是否在课堂上将它们实例化为私有？

将它们标记为内联，例如//稍后删除我

标记需要稍后删除的变量的最佳实践是什么？

(当然没有一个真正有组织的大脑...)

在C＃中，我们为其提供了一个属性：[已过时("使用MethodB代替"")]因此，它的确使我认为Java应该具有类似之处。

根据我的经验，以后修复我通常等同于从不修复，所以无聊的答案是立即修复。

@Johan，有时您仍想将旧方法保留多个版本，例如，使用该库的外部程序在更新时会中断，这会引起客户愤怒。通过将其标记为"过时"或"已弃用"，他们有时间对其进行修复，并且仍然可以进行更新以利用其他错误修复的优势。

@迈克尔先生，绝对。假设，什么情况如此严峻，以至于需要引入一个需要去的变量，而不能用例如@Deprecated方法执行？

@ Johan，Touch。

您不应该拥有太多的方法，以至于无法一次(或在页面滚动中)全部看到它们。您遇到的问题只是一个原因(无法立即记住整个方法的症状)。

@OrangeDog不确定那一个。一些人(如我)首先加载课程，使某项工作正常，然后进行清理。

@JackfromBlisd确实如此，然后您因此而浪费了两个星期。

使用注释@Deprecated

@Deprecated

public void Test() {

//

}

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

@Deprecated

public void speak() {

System.out.println("Meow.");

}

在Wikipedia中，关于Java注释：

Java defines a set of annotations which are built into the

language. Annotations applied to java code: @Override - Checks

that the function is an override. Causes a compile warning if the

function is not found in one of the parent classes. @Deprecated -

Marks the function as obsolete. Causes a compile warning if the

function is used. @SuppressWarnings - Instructs the compiler to

suppress the compile time warnings specified in the annotation

parameters Annotations applied to other annotations: @Retention -

Specifies how the marked annotation is stored—Whether in code only,

compiled into the class, or available at runtime through reflection.

@Documented - Marks another annotation for inclusion in the

documentation. @Target - Marks another annotation to restrict what

kind of java elements the annotation may be applied to @Inherited -

Marks another annotation to be inherited to subclasses of annotated

class (by default annotations are not inherited to subclasses).

最佳实践是使用版本控制。修复错误后，您可以git / hg / svn diff来检查自上次提交以来所做的工作，并删除所有临时更改。如果您需要修复其他错误，但在多个提交中保留"临时更改"，则可以执行部分??提交(git add --patch或hg qrecord)，这样您的"临时更改"就不会被提交或遗忘。对于非常大的临时人员(不是最佳实践，但是可能会发生)，您可以创建一个本地分支，并在此基础上继续使用常规代码。一旦确定要删除"临时更改"，就可以清除所有未提交的更改，然后测试问题。

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

配对提交/推送-因此，只有在与第二个人讨论了代码之后，您才可以提交，第二个人将指向临时代码块并向您询问。希望强迫您在提交该问题之前先解决该问题。

不要使用TODO或其他类似的注释，因为它们永远不会被执行。

如果它已经公开并且正在外部使用，则@Deprecate。

如果您使用的是SVN *，并且所做的更改是应在提交更改之前进行修复的(例如，用于在本地调试/测试的临时更改)，则可以添加// STOP-COMMIT之类的注释并设置一个-commit挂钩，禁止提交包含此文本的任何文件。

这对于标记不应提交给SVN的配置文件的本地更改也很有效。

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

*我想您可以使用许多其他版本控制系统执行类似的操作

我没有评论每个想法/建议，而是想回答一下，然后让您对这个答案进行投票。

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

我认为，有许多因素在起作用，这是由避免产生愚蠢错误或遭受已犯错误的愿望所驱动。我做了一个(很多)。

让我们假设版本控制和团队审查胜过一切。但是超出版本控制范围(假设您将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感到厌烦，这让我很生气。

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

以不会犯此类愚蠢错误的方式来统一您的工作。知道您在进行什么更改以及何时进行。保持冷静。

再次感谢！从社区中吸收最佳实践以融入您的工作真是太好了！

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

拥有一个新的任务标签，例如" REMOVE"，它可以帮助您轻松确定需要删除哪些临时代码。将优先级设置为高。

打开任务视图以检查"删除"任务并采取措施。

请通过下面的链接(也提供了UI截图)

任务标签上的StackOverflow Q / A

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

接下来，我向其中添加一个TODO注释，并使用Deprecated对其进行注释。我知道其他人曾说过TODO从未执行，但是当我进行提交时，我的IDE(在这种情况下为IntelliJ)警告我有X个TODO正在提交。如果您在办理登机手续时收到类似的消息，则应该牢记一个标记。另外，如果您发现自己经常这样做，可以制作一个实时模板，摘要或您的IDE提供的其他任何东西，因此您只需键入类类型和变量名即可。

@Deprecated

Object TODO_REMOVE_variableName;//TODO Remove

最后，我试图重新阅读，理解，改进和确认在检查更改之前编写的每行代码。这是非常重要的！我知道一开始听起来可能令人望而生畏，尤其是对于较大的更改或当您迫在眉睫的最后期限时，但这是您编写代码所花的时间，所揭示的问题以及未来时间的空档。节省是值得的。确实，我希望每个开发人员都这样做。

+1只是用于在签入之前阅读差异。我发现这是代码审查确实有帮助的情况-我通常在发送差异以供审查之前和之后再次检查差异，这使我无法检查临时更改 (或什至只是不必要的更改)太多次了。