- Вызовы методов или функций, которые не имеют никакого значения.
Не обязательно плохо. Методы в базовом классе часто вызывают пустые методы, которые подразумеваются как точки переопределения для подклассов. Пример: UIView Cocoa Touch имеет -didAddSubview:метод, который задокументирован как ничего не делающий в версии по умолчанию. Метод UIView -addSubview:должен вызывать, -didAddSubview:даже если он ничего не делает, потому что подклассы могут реализовать его, чтобы что-то сделать. Конечно, методы, которые ничего не делают, и их причины должны быть задокументированы.
Если пустая или бесполезная функция / метод явно существует по историческим причинам, ее следует удалить. Посмотрите на более ранние версии кода в вашем хранилище исходного кода, если вы не уверены.
- Резервные проверки выполняются в отдельном файле класса, объекте или методе.
Трудно сказать, нормально ли это без контекста. Если проверки явно выполняются по одной и той же причине, это может означать, что нет четкого разделения обязанностей и требуется некоторый рефакторинг, особенно когда обе проверки приводят к выполнению одного и того же действия. Если действие, полученное в результате обеих проверок, не совпадает, то две проверки, вероятно, выполняются по разным причинам, даже если условие одинаково, и это, вероятно, хорошо.
- если утверждения, которые всегда оцениваются как истинные.
Есть большая разница между:
if (1) {
// ...
}
а также:
if (foo() == true) {
// ...
}
где foo()случается всегда возвращаться true.
Первый случай часто случается, когда люди отлаживают. Это легко использовать , if (0) {...чтобы временно удалить фрагмент кода , когда вы пытаетесь изолировать ошибку, а затем изменить , 0чтобы 1восстановить этот код. ifДолжно быть удалено , как только вы сделали, конечно, но это легко забыть этот шаг, или пропустить один или два , если вы сделали это в нескольких местах. (Это хорошая идея, чтобы идентифицировать такие условия с помощью комментария, который вы можете искать позже.) Единственный вред - это путаница, которую он может вызвать в будущем; если компилятор может определить значение условия во время компиляции, он полностью удалит его.
Второй случай может быть приемлемым. Если условие, представленное символом, foo()необходимо проверить из нескольких мест в коде, выделение его в отдельную функцию или метод часто является правильным решением, даже если foo()в настоящий момент оно всегда выполняется. Если возможно, что это foo()может в конечном итоге вернуться false, то выделение этого условия в методе или функции является одним из способов определения всех мест, где код опирается на это условие. Однако выполнение этого создает некоторый риск того, что foo() == falseусловие будет непроверенным и может привести к проблемам позже; решение состоит в том, чтобы убедиться, что вы добавили модульные тесты, которые явно тестируют falseкейс.
- Потоки, которые крутятся и ничего не делают из заметок.
Это звучит как исторический артефакт и нечто, что может быть идентифицировано либо во время проверки кода, либо через периодическое профилирование программного обеспечения. Я предполагаю, что это могло быть создано намеренно, но мне трудно представить, что кто-то действительно сделает это нарочно.
if (false) {...}блоки отлично подходят для комментирования кода! </