пустые строки в функциях/методах
На Рождественской партии нашей компании у нас было почти физическая борьба по одной проблеме: позволить ли пустые строки в функции/методе в нашем коде (c/c ++/c#). Это - все о просто единственной пустой строке, например, вообразите код как:
private void LoadData()
{
if (!loaded)
return;
DataStore coll;
SqlData s = new SqlData();
if (!s.CallStoredProcedureToStore(out coll, "xy.usp_zzz",...))
return;
dataViewXy.BeginUpdate();
dataViewXy.Items.Clear();
for(int i = 0; i < coll.RowCount; i++)
{
dataViewXy.Items.Add(coll[i]["ID"]);
}
dataViewXy.EndUpdate();
}
это - бессмысленное соединение, только для иллюстрирования ситуации - первый блок функциональных данных загрузок, второй заполняет некоторое управление данными, и пустая строка разделяет их.
Нужно было также записать комментарий перед каждым 'блоком', но важная вещь состоит в том, что для парней поместил бы пустую строку, прежде чем тот комментарий и против парней не будет.
Для: Позволяет программисту логически разделять части функции, таким образом, она улучшает удобочитаемость как некоторые добрые визуальные индикаторы для глаз для следования
Против: удобочитаемость Уменьшений и программист должны использовать комментарий для разделения частей функции вместо этого.
Мое личное мнение состоит в том, чтобы позволить пустые строки в функциях, потому что без них длинные части кода смотрят на меня как никогда конечный поток строк без любых сигналов о том, где найти материал, я ищу),
6 ответов
Это будет классная дуэль, которую стоит посмотреть. Точно так же, как финальная сцена в Хорошее, плохое и уродливое , но с пробелом метода вместо золота.
Честно говоря, это не должно иметь значения, если только вам не нужно постоянно обдумывать чужой код в вашей команде на довольно частой основе. Лично я сторонник пробелов, поскольку они дают логическую группировку. Но для кого-то может быть иначе. Черт возьми, даже я мог бы со временем изменить то, как я группирую вещи. Сгруппированные элементы, которые раньше имели смысл, больше не имеют смысла.
Независимо от того, как мы группируем элементы, я думаю, что группировка очень важна. Мы можем спорить, почему пустые строки не нужны, но факт в том, что мозг может обрабатывать только ограниченный объем информации за раз. Так что, если я могу понять, что функция состоит, например, из трех подгрупп, а не из десяти операторов, это имеет большое значение. А группировка по комментариям зависит от вашей IDE. Большинство IDE окрашивают их легче, чем остальной код, что дает ощущение разделения, но это становится специфичным для IDE.
Итак, чтобы отстаивать точку зрения, все дело в группировке. Если класс становится слишком большим, мы должны разбить его для понимания и обслуживания. Точно так же, если последовательные строки кода внутри метода становятся слишком понятными, он должен быть разбит на несколько методов или логически разделен пустой новой строкой.
Кроме того, если аргумент ни к чему не приводит, добавьте случайные вещи вроде того, как эти пустые строки относятся к буддийской концепции небытия бла бла ..
"Один размер подходит всем" такие правила не работают.
Есть допустимые аргументы за и против каждой точки зрения, например, я мог бы противопоставить ваш аргумент "длинные строки кода", сказав, что такие функции должны быть разбиты на подпроцедуры.
Однако, это не относится к делу.
Говорить одно "ДОЛЖНО" вставлять пустые строки так же бессмысленно, как и говорить одно "Нельзя вставлять пустые строки".
BW закон в таких ситуациях - "используй то, что работает для тебя"
Если это должно быть решено, проголосуй и пусть все согласятся подчиниться голосу до того, как будет проведено голосование (даже ты, если ты проиграешь).
Это мои два цента.
P.S. Мое личное мнение касается пустых строк.
Определенно для, хотя этот вопрос может быть субъективным.
Кроме того, я научился разделять метод, если он становится слишком большим, скорее, может "сжимать" его, удаляя входы.
Физический бой? На рождественской вечеринке? Похоже на весёлое место.
Я тоже за белые пробела, когда это улучшает читабельность. Это часть причины, по которой я также выступаю за выравнивание фигурных скобок: лишние белые пробелы визуально снимают блок кода.
Большинство комментариев беспорядочны и не помогают читабельности. Если они не добавляют информацию, помогающую понять код, они только мешают.
Похоже, я бы боролся с толпой "никаких пробельных/добрых комментариев"
.] Мое эмпирическое правило заключается в том, чтобы помещать все объявления переменных в начало функции, за которой следует обработка, а затем оператор возврата (если таковой имеется), каждый из которых отделяется пустыми строками.[
] [
int DoSomething(string robot)
{
int result = 0;
if (robot == "robot")
result = 42;
return result;
}
]
[] Если это умеренно сложный метод с логически различимыми блоками кода, которые не требуют инкапсуляции в собственных методах, то я их тоже разобью пробелами. Все, что может приравниваться к 'абзацу' кода, отделяется пустой строкой [
]. [] Большинство комментариев я оставляю в блоках комментариев []///[] вверху метода. [
Я за пробелы - это незначительное использование памяти, которое значительно улучшает читаемость кода за счет разделения программы на логические шаги. Однако это не заменяет хорошие комментарии . Мое правило комментирования: `` Старайтесь не делать того, что раздражает в коде других людей (который обычно оказывается не комментирующим. индивидуальный комментарий, я полагаю)
У нас много места для хранения и мониторы хорошего размера, так почему бы не использовать его, чтобы упростить работу?
Однако огромные куски пробелов могут вытеснять код с экрана, что мешает работе возможность взглянуть на код и получить хороший обзор, так что лучше не переусердствовать.
Как и все в программировании, все зависит от конкретного случая, личных предпочтений и намеков на модерацию.