Короткий ответ - нет. Модульные тесты не являются местом для объектов UIView и манипулирования объектами UI. Вы хотите добавить цель тестирования пользовательского интерфейса для такого рода тестов.
Лучшая практика должна написать код, который другие могут прочитать и обновить легко.
Ваша первая форма сомнительна, потому что она не следует за формами, к которым привыкло большинство разработчиков PHP:
if (condition) {
// code
} else {
// code
}
// ... or ...
if (condition)
{
// code
}
else
{
// code
}
// ... or ...
if (condition) { /* short code */ } else { /* short code */ }
// ... or ...
condition ? /* short code */ : /* short code */;
Обратите внимание, что это полностью об общепринятой практике и не обязательно имеет смысл — это только, о каком другие разработчики привыкли видеть.
Ваша вторая форма, что еще более важно, не так хороша, потому что она помогает другому программисту сделать эту ошибку:
if (condition)
// code A
else
// code B
// code C (added by another programmer)
В этом примере добавил другой программист code C
, но забыл переносить целое else
блок в фигурных скобках. Это вызовет проблемы. Можно защитить от этого путем простого обертывания Вашего if
и else
блоки в фигурных скобках.
Мое предпочтение, если для непротиворечивости... так:
if(...)
{
statement 1;
statement 2;
}
else
{
statement 1;
statement 2;
}
не отличается, чем:
if(...)
{
statement 1;
}
else
{
statement 1;
}
Таким образом, я всегда использую их, потому что это последовательно, и это избегает проблем, забывающих включить их позже.
Однако другие люди будут смотреть на мой код и думать, что глупо вставить {и}. У них есть свои причины, у меня есть мои... Мне, оказывается, нравятся мои причины больше, чем мне нравятся их :-)
Проблемой, которую я видел, являются разработчики, не распознающие {}-less-if, когда они добавляют код к одному из условий. Пример:
//before
if(something)
statement;
//after
if(something)
statement;
addedstatement;
Очевидно, это не сделает то, что они ожидают.
Обычно нечитаемый код является плохой практикой. Одна строка более эффективна в Вашем вводе и сохраняет номера строки, но возвратитесь к нему год с этого времени или в то время как Вы сканируете для ошибок, и это сделает это более трудным.
По-моему, да это - плохая практика, чтобы иметь одну строку если операторы.
Компьютер действительно не заботится (насколько я могу сказать), но необходимо всегда писать код как, он будет сохраняемым серийным убийцей, который знает, где Вы живете.
Читаемый! Легко саморазличимый.
Вы когда-либо видели код как это в C или C++?
/* Warning: bogus C code! */
if (some condition)
if (another condition)
do_something(fancy);
else
this_sucks(badluck);
Или добавление отступа является неправильным, или программа багги, потому что "еще" всегда относится к ближайшему, "если", если Вы не используете фигурные скобки.
(Позвольте нам просто использовать Python. Никакие скобки, просто чистые чистые пробелы.:P)
Для всех кроме самых коротких операторов используйте фигурные скобки и расположите их с интервалами соответственно. Вы хотите сделать это по нескольким причинам:
Более трудно сделать ошибку о том, куда что-то идет.
Легче читать.
На языках со средствами макрорасширения (например, C, C++), отказ включать фигурные скобки вызовет запутывающие логические ошибки, когда макрос, содержащий несколько операторов, будет расширен в ослабленном if-else
.
Одно главное преимущество использования нескольких строк является простотой отладки. Если Вы имеете, если еще оператор, все на одной строке и отладчике говорят Вам, что строка x аварийно завершилась, более трудно определить, какая часть оператора перестала работать. Несколько строк также помогают ступить через Ваш код с помощью отладчика.
Это - две строки долго, таким образом, не действительно одна строка.
Нет ничего неправильно с одной строкой if
s, когда это делает код легче читать.
Например, что-то вроде этого:
if (last_item) print ", and " else print ", "
намного лучше, чем
if (last_iem)
{
print ", and "
}
else
{
print ", "
}
Это - больше стиля кодирования, чем что-либо еще. Тем не менее мое личное мнение - то, что Ваш второй пример потенциально довольно вреден. Достаточно легко случайно, "добавьте вторая строка к блоку" на языках, где фигурные скобки являются единственным способом создать блоки. Но в PHP, где альтернативный синтаксис существует, это, еще менее вероятно, выделит необходимые звонки предупреждения:
if ($_GET["asdf"]==1):
/* do something */
else:
/* do something */
endif;
Эмпирическое правило: если Вы собираетесь поместить Ваш, "делают что-то" на отдельной строке, используют фигурные скобки; если Вы не собираетесь использовать фигурные скобки, поместите его на ту же строку!
Я видел так многих сторонний код с глупыми проблемами, что я предпочитаю использовать фигурные скобки все время. Это сказало, что я никогда не чувствовал себя хорошо на
if(){}
else (){}
Я использую, если () {} на той же строке, когда это - короткая команда и это является одним. Если еще существует использование длинное:
if(checkSomething)
{
//dosomething
}
else
{
//doanotherthing
}
Это - что-то, что я на самом деле помню от экзамена занятости некоторое время назад. Код был подобен следующему:
if (x == 0)
x = 2;
else
print("x is: %d", x); // debugging!
x = 4;
Большинство людей здесь может определить ошибку, но можно действительно занять место в чем-либо, что Вы хотите как "плохой код", который был введен. Более тонкая ошибка прибывает, когда у Вас есть "старая версия" чего-то прокомментированного, и кто-то не комментирует это, и внезапно второй оператор вне блока.
В основном, если это не маленькое тестовое приложение для изучения понятия быстро, я всегда скобка (и даже в тестовых приложениях я обычно скобка). Это просто не стоит головной боли позже, если я не делаю, даже в 5 методах строки.
Необходимо поместить, "если" и "делают что-то" на отдельных строках для создания кода более дружественным по отношению к интерактивным отладчикам.
Если Вы помещаете и, "если" и "делают что-то" на той же строке, то Вы не можете установить точку останова только на, "делают что-то" строка.