Какова наилучшая практика для маркировки переменных, которые нужно удалить позже в Java?

Я почесал голову на две недели, пытаясь вычислить что-то, основанное на переменной.

Оказывается, я установил переменную раньше, чтобы временно решить другую проблему и никогда не возвращался, чтобы исправить ее.

Обычно я пытаюсь пометить код с помощью //ToDo, чтобы напомнить мне удалить временную переменную.

В этом случае я не отмечал его, так как я проскакивал, пытаясь исправить больше, чем несколько вещей. (Я не мог понять, что происходит, поэтому я пытался всевозможные вещи!)

Как вы отмечаете временные переменные, которые вы хотите удалить позже?

  • Вы создаете их как частные в верхней части класса?
  • Отметьте их строкой с помощью чего-то вроде //Delete Me Later

Какова наилучшая практика для маркировки переменных, которые вам нужно удалить позже?

(не имея действительно организованного мозга, конечно...)

ОТВЕТЫ

Ответ 1

Вместо того, чтобы комментировать каждую идею/рекомендацию, я думал, что я отвечу, а затем вы проголосуете за этот ответ.

Во-первых, большое спасибо за то, что вы делитесь своими процессами и идеями. Я действительно ценю это.

Я думаю, что в игре есть ряд факторов, которые должны быть обусловлены стремлением избежать глупых ошибок или страданий от тех, которые вы уже сделали. Я сделал один (из многих).

Предположим, что контроль версий и обзоры команд козыряют все; однако вне контроля версий (предполагая, что вы сделали crappola своему хорошему коду):

  • @Deprecated очень хорошо. Кажется, он близок к вам. Нам всем нужно вопиющим. Надеюсь, мы увидим лес через деревья.

  • Для меня различия являются обременительными, поскольку я часто делаю радикальные изменения, но это большое предложение, которое работает во многих случаях.

Некоторые заметные вещи:

Поскольку я обычно являюсь единственным разработчиком, я полагаюсь на ToDos. Они просты в использовании. У меня есть неофициальная рейтинговая система с 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, и он меня сжег.

Самое большое правило, возможно, из всего этого:

Унифицируйте свою работу таким образом, чтобы вы не делали глупых ошибок, подобных этому. Знайте, какие изменения вы делаете и когда. Сохраняйте спокойствие.

Еще раз спасибо! Это здорово подобрать лучшие практики сообщества, чтобы включить в вашу работу!

Ответ 2

Используйте аннотацию @Deprecated

@Deprecated
public void Test() {
  //
}

Ответ 3

Нашел его после нескольких поисковых запросов, так как мне было любопытно.

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

Из Википедии, аннотации Java:

Java определяет набор аннотаций, которые встроены в язык. Аннотации, применяемые к java-коду: @Override - Checks что функция является переопределением. Вызывает предупреждение компиляции, если функция не найдена в одном из родительских классов. @Deprecated - Отмечает функцию как устаревшую. Вызывает предупреждение компиляции, если функция используется. @SuppressWarnings - инструктирует компилятор для подавлять предупреждения времени компиляции, указанные в аннотации Параметры Аннотации, применяемые к другим аннотациям: @Retention - Указывает, как сохраняется отмеченная аннотация - только в коде, скомпилирован в класс или доступен во время выполнения через отражение. @Documented. Помечает еще одну аннотацию для включения в документация. @Target - помещает еще одну аннотацию для ограничения того, что вид элементов java, аннотация может быть применена к @Inherited - Отмечает еще одну аннотацию, которая будет унаследована подклассам аннотированных класс (по умолчанию аннотации не наследуются для подклассов).

Ответ 4

Лучшей практикой является использование контроля версий. Как только вы исправили ошибку, вы можете git/hg/svn diff проверить, что вы сделали с момента последнего фиксации, и удалить любые временные изменения. Если вам нужно исправить другие ошибки, но сохраните "временное изменение" за несколько коммитов, вы можете сделать частичные коммиты (git add -patch или hg qrecord), чтобы ваши "временные изменения" никогда не были зафиксированы и не забыты. Для очень больших временных периодов (не самая лучшая практика, но это может произойти), вы можете создать локальную ветвь, которую вы продолжаете перестраивать над нормальным кодом. После того, как вы обязательно удалите "временные изменения", вы можете просто очистить любые незафиксированные изменения и затем проверить наличие проблем.

Ответ 5

Локальные ветки (git, изменения стеллажей в IntelliJ, две копии источника проверены локально), поэтому, когда вы перемещаетесь из одной задачи в другую, вместо того, чтобы просто работать над частично выполненной работой, вы создаете вторую ветвь и не фиксировать/нажимать первую, пока она не будет завершена.

Пара фиксирует/толкает - так что вы не совершаете, пока не поговорите с кодом со вторым человеком, который укажет на временный фрагмент кода и спросит вас об этом. Надеюсь, вам удастся исправить эту проклятую проблему, прежде чем совершать ее.

Не используйте TODO или другие подобные комментарии, так как они никогда не будут действовать.

Если он уже общедоступен и используется извне, то @Deprecate.

Ответ 6

Во-первых, я предваряю каждое имя переменной "TODO_REMOVE_" или что-то подобное. Таким образом, если я забуду удалить его, и кто-то встретит его позже, ясно, что переменная должна быть удалена. Кроме того, если я сделаю последний шаг ниже, я ВСЕГДА удалю его, прежде чем проверять его.

Затем я добавляю к нему комментарий TODO и аннотирую его с помощью устаревших. Я знаю, что другие говорили, что TODO никогда не действуют, но когда я делаю фиксацию, моя IDE (IntelliJ в этом случае) предупреждает меня, что есть X TODOs. Если вы получите аналогичное сообщение, когда вы проверите, это должно бросить флаг в вашем уме. Кроме того, если вы часто это делаете, создайте живой шаблон, фрагмент кода или что-то еще, что предоставит вам IDE, поэтому вам нужно только ввести тип и имя класса.

@Deprecated
Object TODO_REMOVE_variableName;//TODO Remove

Наконец, я пытаюсь перечитать, понять, улучшить и подтвердить КАЖДУЮ строку кода, которую я пишу, прежде чем проверять внесенные изменения. Это CRUCIAL! Я знаю, что это может показаться пугающим сначала, особенно для больших изменений или когда у вас надвигающийся крайний срок, но это падение в ковше рядом с тем временем, когда вам потребовалось написать код, а также проблемы, которые он раскрывает, и будущее время это экономит, стоит того. Воистину, я желаю, чтобы каждый разработчик сделал это.

Ответ 7

Если вы используете Eclipse, я предлагаю вам

У вас есть новый тег задачи, например "REMOVE", который поможет вам легко определить, какой временный код нужно удалить. Установите приоритет на Высокий.

Откройте представление задач, чтобы проверить выполнение задач REMOVE и принять меры.

Пройдите по ссылке ниже (снимок экрана пользовательского интерфейса)

fooobar.com/questions/51200/...

Ответ 8

Если вы используете SVN *, и изменение, которое вы делаете, должно быть исправлено до того, как ваши изменения будут выполнены (например, временное изменение для отладки/тестирования локально), вы можете добавить комментарий, например // STOP-COMMIT, и установить чтобы запретить запись любого файла, содержащего этот текст.

Это также хорошо подходит для маркировки локальных изменений в файлах конфигурации, которые не должны быть привязаны к SVN.

Если ваша IDE поддерживает список TODO, который ищет комментарии для данной строки, вы даже можете создать собственный формат TODO, который ищет эту строку.

* Я бы предположил, что вы можете сделать что-то подобное со многими другими системами управления версиями