Здравствуйте, Enomay, Вы писали:

R>>Ну я вот специально ещё раз перечитал стартовое сообщение и для меня до сих пор не очевидно, что вопрос обнаружения мёртвого кода автоматически исключён из обсуждения. А по моему личному опыту, многие программисты часто увлекаются такими "очистками" и тратят на это времени больше, чем нужно. А бывает, ещё и ошибочно детектят код, как неиспользуемый, чем создают дополнительные проблемы. При этом не могут ответить на простой вопрос: "а нафига ты туда вообще полез?".

E>Не знаю, как в других языках, но на C# тебе прям студия подствечивает метод или класс, который вообще нигде не используется.
E>Ну и code guards как правило на больших проектах настроены и не позволяют заливать разную ерунду.

Студии, конечно, низкий поклон за то, что она облегчает работу программиста. Но даже у студии не всегда есть полная информация для того, чтобы правильно продетектить мёртвый код. Сборки могут подгружаться внешними приложениями при помощи LoadAssembly, классы и методы могут использоваться через рефлесию и т.п. Лично для меня главным критерием внесения изменений в является степень пересечения данного кода, с той задачей, которую я в данный момент выполняют. Просто вот с точки зрения минимизации зависимостей по коду — у каждой задачи есть некоторый скоуп, по которой определяются все её зависимости. И я без супер-острой необходимости никогда не полезу вносить изменения за границы этого скоупа, пускай там хоть одичалые сношаются с белыми ходоками.

Здравствуйте, Enomay, Вы писали:

R>>Ну я вот специально ещё раз перечитал стартовое сообщение и для меня до сих пор не очевидно, что вопрос обнаружения мёртвого кода автоматически исключён из обсуждения. А по моему личному опыту, многие программисты часто увлекаются такими "очистками" и тратят на это времени больше, чем нужно. А бывает, ещё и ошибочно детектят код, как неиспользуемый, чем создают дополнительные проблемы. При этом не могут ответить на простой вопрос: "а нафига ты туда вообще полез?".

E>Не знаю, как в других языках, но на C# тебе прям студия подствечивает метод или класс, который вообще нигде не используется.
E>Ну и code guards как правило на больших проектах настроены и не позволяют заливать разную ерунду.

Студии, конечно, низкий поклон за то, что она облегчает работу программиста. Но даже у студии не всегда есть полная информация для того, чтобы правильно продетектить мёртвый код. Сборки могут подгружаться внешними приложениями при помощи LoadAssembly, классы и методы могут использоваться через рефлесию и т.п. Лично для меня главным критерием внесения изменений в код является степень пересечения данного кода, с той задачей, которую я в данный момент выполняю. Просто вот с точки зрения минимизации зависимостей по коду — у каждой задачи есть некоторый скоуп, по которому определяются все её зависимости. И я без супер-острой необходимости никогда не полезу за эту стену, пускай там хоть одичалые сношаются с белыми ходоками.