Вы проверяете новый код, который не имеет непосредственного применения? - PullRequest
0 голосов
/ 05 ноября 2010

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

Позже я понял, что яможет решить большую проблему совершенно по-другому.Мне не нужно было бы вызывать мой новый метод вообще.Функция может быть полезна для решения какой-то проблемы в будущем, но если я проверю ее сегодня, она сразу станет мертвым кодом.Что мне с этим делать?Проверить это?Проверить это, но # ifdef'd out?Проверить это и немедленно сделать еще один коммит, чтобы удалить его?Оставить это в гадости?Просто принять потерю и двигаться дальше?

Ответы [ 3 ]

3 голосов
/ 05 ноября 2010

Если это ваша личная ветка разработчика, отметьте ее и отметьте. Убедитесь, что вы не объединяете его с какой-либо функцией или веткой версии, над которой вы работаете. У меня есть папка с набором свойств svn:ignore, который предотвращает случайное добавление такого рода вещей в основную ветку.

2 голосов
/ 05 ноября 2010

Не регистрируйте мертвый код в производственном дереве. Если вы думаете, что когда-нибудь в будущем вы сможете использовать этот код, зарегистрируйте его в своем личном хранилище.

Все, что находится в дереве продукта, связано с проверкой стоимости, проверкой кода, разработкой документации, описанием публичного API, моделированием потоков, обслуживанием и т. Оплата этой стоимости за код, который не используется, означает, что вам придется меньше тратить на реальные функции для своих пользователей.

0 голосов
/ 05 ноября 2010

Это полностью зависит от вас и (если применимо) политики в вашей компании.

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

, тогда я бы не советовал оставлять его #ifdef или оставлять еговнутри рабочего кода, потому что, когда кто-то еще читает, использует ваш код, ему будет сложнее следить за ходом вашей программы.(в моей работе у нас есть несколько проектов, которые компилируются для настольных ПК, DS, PSP и т. д., и когда вам нужно прочитать код с несколькими #define, это сложно: нет необходимости усложнять его: P.

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

надеюсь, что это поможет

Джейсон

...