C# code style: Нужны или не нужны пустые строки внутри метода?
Каким образом пустой строкой можно разделить логику метода?если в одном методе делаются слабо связанные между собой действия - то они должны быть разделены пустыми строками, комментарии для этого не нужны
если в одном методе делаются слабо связанные между собой действия - то они должны быть разделены пустыми строкамиЕсли в одном методе делаются слабо связанные действия, то они должны быть вынесены в два метода. Я не знаю, как определять "связность" действий в пределах метода.
Я не знаю, как определять "связность" действий в пределах метода.Опять же, почему тот же самый программист пишет:
projectController.HideView;Почему здесь нету пустой строки? Я могу сделать только один вывод: полный рандом. Пустые строки вставляются от балды чаще, чем по каким-то логически обоснованным соображениям.
loginController.DoLogout;
mainView.HideView;
Проверка параметров конструктора и инициализация полей объекта, например, - слабо связанные действия.
Проверка параметров конструктора и инициализация полей объекта, например, - слабо связанные действия.И код будет более читаемый, если они будут разделены не пустой строкой, а таким, например, коментарием:
// проверка условий для вызова
if (disposed)
throw new ObjectDisposedException("cannot invoke methods on a disposed service proxy");
if (method == AUTHORIZE_METHOD)
throw new InvalidOperationException("the Authorize method must not be called explicitly");
// вызываем метод, пока обрабатываются исключения
....
// проверка условий для вызоваа я обычно и комментарии и пустые строки ставлю:
if (disposed)
throw new ObjectDisposedException("cannot invoke methods on a disposed service proxy");
if (method == AUTHORIZE_METHOD)
throw new InvalidOperationException("the Authorize method must not be called explicitly");
// вызываем метод, пока обрабатываются исключения
....
// проверка условий для вызоваТак глаз сразу видит отдельные блоки, и на начало нового блока переходить глазами проще.
if (disposed)
throw new ObjectDisposedException("cannot invoke methods on a disposed service proxy");
if (method == AUTHORIZE_METHOD)
throw new InvalidOperationException("the Authorize method must not be called explicitly");
.
// вызываем метод, пока обрабатываются исключения
блаблабла
....
Это как выравнивание текста по левому краю в книжках, чтобы было проще начало строки находить
camel case underscoreв джаве нет такого
ну тойсть оно конечно есть у например лиц пришедших с с++
но в общепринятом нет
извини, но для меня этот твой код не читаем
первый я коммент удалимл потому что он бессмысленный
второй комент имеет смысл, поэтому оставил
логический код-блок пошел другой => добавил пустую строку
ну и все ифы должны со скобками идти, без скобок могут быть токо повторяющиеся ифы написанные на одной строке
if (disposed) {
throw new ObjectDisposedException("cannot invoke methods on a disposed service proxy");
}
if (method == AUTHORIZE_METHOD) {
throw new InvalidOperationException("the Authorize method must not be called explicitly");
}
// вызываем метод, пока обрабатываются исключения
....
первый я коммент удалимл потому что он бессмысленный
второй комент имеет смысл, поэтому оставил
логический код-блок пошел другой => добавил пустую строку
ну и все ифы должны со скобками идти, без скобок могут быть токо повторяющиеся ифы написанные на одной строке
if (a == 5) return "yes";
if (a == 3) return "no";
return "maybe";
скобочки для одного оператора это тру. только я больше люблю, когда они друг под другом
if (disposed)
{
throw new ObjectDisposedException("cannot invoke methods on a disposed service proxy");
}
if (method == AUTHORIZE_METHOD)
{
throw new InvalidOperationException("the Authorize method must not be called explicitly");
}
// вызываем метод, пока обрабатываются исключения
....
извини, но для меня этот твой код не читаемИзвини, но надо знать причины по которым в Java ставятся { } для одного выражения. Читаемость тут не при чём. В C# такой практики де факто нет, хотя ты и мог бы её использовать.
Точно так же в C# не практикуется { на той же строке.
Если в одном методе делаются слабо связанные действия, то они должны быть вынесены в два метода. Я не знаю, как определять "связность" действий в пределах метода.О как... Очень бы хотелось посмотреть на пример кода людей, которые ставят пустые строки в нужных местах. Причём так, чтобы они были реально необходимы именно в этих местах, и чтобы всем сразу стало ясно, что ни больше, ни меньше пустых строк в методе быть не может.
чтобы всем сразу стало ясно, что ни больше, ни меньше пустых строк в методе быть не может.бред какой-то..
ты еще также скажи:
Очень бы хотелось посмотреть на пример кода людей, которые используют объекты в нужных местах. Причём так, чтобы они были реально необходимы именно в этих местах, и чтобы всем сразу стало ясно, что ни больше, ни меньше объектов быть не может.
Очень бы хотелось посмотреть на пример кода людей, которые используют разбиение на методы в нужных местах. Причём так, чтобы они были реально необходимы именно в этих местах, и чтобы всем сразу стало ясно, что ни больше, ни меньше методов быть не может.
Очень бы хотелось посмотреть на пример кода людей, которые используют комментарии в нужных местах. Причём так, чтобы они были реально необходимы именно в этих местах, и чтобы всем сразу стало ясно, что ни больше, ни меньше комментариев быть не может.по теме: сколько людей, столько и мнений.
имхо, код с "хорошим запахом" должен иметь пустые строки, которые отделяют одну отдельную часть метода от другой части.
у каждого программиста, конечно будет какая-то своя стратегия расстановки пустых строк, способ определения что такое отдельная часть метода - может даже гулять от случая к случаю у одного и того же программиста. но в целом - идея одна и та же (пытаемся выделить отдельные части и полезная.
ps
писать комментарии внутри метода - имхо, зло.
если хочется написать комментарий внутри метода - то это скорее отдельный метод.
а вот отбивка пустыми строками - подход правильный
из реального старого проекта
в первом методе - выделяются три части: создание источника данных, настройка привязки, запуск
во втором методе - отделяются трасировочные вызовы от нормальных
protected void OutputFilms(DataTable filmsTable, string filter)
{
DataView filmsView = new DataView(filmsTable,
...);
Films_List.DataSource = filmsView;
Films_List.DataTextField = "FullName";
Films_List.DataValueField = "Id";
Films_List.DataBind;
}
protected void Page_Load(object sender, System.EventArgs e)
{
Trace.Write("Page_Load");
if (!IsPostBack)
{
Trace.Write("LoadActors");
OutputFilms(FilmsData.GetFilmsTable "");
}
}
в первом методе - выделяются три части: создание источника данных, настройка привязки, запуск
во втором методе - отделяются трасировочные вызовы от нормальных
а вот отбивка пустыми строками - подход правильныйНу и где аргументы, кроме холиварных?
Если что-то в коде находится в ненужном месте, то это что-то нужно либо убрать, либо отрефакторить. Это относится и к объектам, и к методам, и к коментариям. Я не могу понять и не вижу никаких аргументов в пользу того, что куча пустых строк, расставленных случайным образом положительно влияет на читаемость кода. В то время как коментарии внутри метода таки помогают понять, что же происходит в следующих нескольких строках.
расставленных случайным образомключевые слова были(но ты их почему-то пропустил): что пустые строки ставятся там, где хочется выделить отдельные части метода, но само разбиение на части (также как и все остальное: разбиение на методы, объекты и т.д.) - конечно, сильно зависит от автора
конечно, сильно зависит от автораВот это и есть ключевой момент. Если лично ты что-то выделяешь пустыми строками, то это вполне может быть неочевидно другому программисту. И он скорее протупит, понимая, почему ты поставил тут пустую строку, чем быстро проскочит на следующий "логический блок".
И он скорее протупит, понимая, почему ты поставил тут пустую строку, чем быстро проскочит на следующий "логический блок".на самом деле, мне вообще странно услышит, что кто-то в первый раз видит и не понимает, что такое разбиение метода на отдельные части, и зачем это надо.
большинство из хороших(понятных) кодов, которые я видел - имели разбиение методов на отдельные части.
и в большинстве случаев понятно, что именно хотел сказать автор, когда делал такое разбиение.
попробуем такой аргумент: я бы кое-где пустыми строками выделял ту часть метода, которая жрет большую часть ресурсов.
что-то типа
что-то типа
блаблаблабла
аблаблабла
аблаблабла
show; или какой-нибудь load;
блаблабла
аблаблабла
в первом методе - выделяются три части: создание источника данных, настройка привязки, запускДа, больше пустых строк в этом коде не требуется. То есть ДОСТАТОЧНОСТЬ ты показал. А вот НЕОБХОДИМОСТЬ - нет. Тем более здесь 5 строк кода, это какими даунами должны быть люди, неспособные прочитать и осмыслить 5 строк без пустышек внутри?
во втором методе - отделяются трасировочные вызовы от нормальных
я бы кое-где пустыми строками выделял ту часть метода, которая жрет большую часть ресурсов.Да сейчас можно десятки способов разбиения придумать. Вопрос не в этом, а в том, с какого бодуна это повышает читаемость?
блин
причем тут дауны/понять/осмыслить
это делается для наглядности а не потому чт отак уж прям сильно непонятно
ты фактически вот что говоришь: "это какими же даунами должны быть люди, неспособные прочитать и осмыслить код написанный полностью в одну строчку"
причем тут дауны/понять/осмыслить
это делается для наглядности а не потому чт отак уж прям сильно непонятно
ты фактически вот что говоришь: "это какими же даунами должны быть люди, неспособные прочитать и осмыслить код написанный полностью в одну строчку"
большинство из хороших(понятных) кодов, которые я видел - имели разбиение методов на отдельные части.В большинстве случаев, когда я задумывался над кодом автора, я понимал, что разбиение вообще случайно.
и в большинстве случаев понятно, что именно хотел сказать автор, когда делал такое разбиение.
это делается для наглядности а не потому чт отак уж прям сильно непонятноМне непонятно, откуда берётся наглядность?
...
вам не кажется, что это попахивает уже пенартуром?...
В большинстве случаев, когда я задумывался над кодом автора, я понимал, что разбиение вообще случайно.и?
что ты хочешь этим сказать?
по моей практике я очень редко вижу хорошо отформатированный код
вот прям щас код коллеги напротив
/**
* To use by RParser from RDataSource event thread <br>
* @param level = from <code>0</code> to <code>capacity-1</code>
*/
void updateBidPrice(int level,double price) {
if (level>=capacity) throw new IllegalArgumentException("Couldn't update level ["+level
+"], it's higher than capacity ["+capacity+"]");
data[level] = price;
// wrong thing. price = 0 usually means market order
// if (price<10e-5 && bidDeep>level) bidDeep = level; // price==0 - empty level --> deep == iNonzerolevel+1 == level
// else
if (bidDeep<level+1) bidDeep = level+1; // level is higher than deep, improve deep
}
/**
* To use by RParser from RDataSource event thread <br>
* @param level = from <code>0</code> to <code>capacity-1</code>
*/
void updateBidSize(int level,double size) {
if (level>=capacity) throw new IllegalArgumentException("Couldn't update level ["+level
+"], it's higher than capacity ["+capacity+"]");
data[capacity+level] = size;
if (size<10e-5 && bidDeep>level) bidDeep = level; // size==0 - empty level --> deep == iNonzerolevel+1 == level
else if (bidDeep<level+1) bidDeep = level+1; // level is higher than deep, improve deep
}
о каких нах пустых строках может идти речь если он даже знаки пробелами не отделяет?
если по начальным твоим примерам, то там понятная идея автора:
здесь три разных фазы
//сделать три явных действия
здесь три разных фазы
//настройка: show форму реально не фига не показывает
mainView.Show;
//прямые действия
loginController.DoLogin;
projectController.Execute;
//запуск механизма: которые выполнит отложенные действия + будущие действия
mainView.RunMessageLoop;
//сделать три явных действия
projectController.HideView;
loginController.DoLogout;
mainView.HideView;
надеюсь, ты ему прямо там на месте пробил в табло?
надеюсь, ты ему прямо там на месте пробил в табло?у него железный аргумент: "руками пробелы мне расставлять лень, а автоформатингом эклипсовским я воспользоваться не могу потому что он гавно"
поддерживаю. Как раз то, о чем я говорил - отделение пустого порожнего кода в метода, т.е мало что делающего по сути мусора, от реальных действий
Да сейчас можно десятки способов разбиения придумать. Вопрос не в этом, а в том, с какого бодуна это повышает читаемость?с того самого, что если автор приучен мыслить в терминах отдельных частей - отбитыми пустыми строками, то код внутри метода получается стройный, а не некое спагетти.
т.е. речь о том, что если автор не вставляет пустые строки, то больше вероятность, что он пишет тяжелый для понимания код, не имеющий явно записанной внутренней логики.
//настройка: show форму реально не фига не показываетПоказывает. Это MVP вызов интерфейса основного представления.
он считает что
1) метод должен осмысленно называться
2) если пункта 1 недостаточно то у метода должны быть джавадоки
3) все остальное что внутри метода неважно, тот кто будет его править или там дебажить - ему по любому нада будет разбираться в каждой строчке а тогда уже пофиг какое форматирование
1) метод должен осмысленно называться
2) если пункта 1 недостаточно то у метода должны быть джавадоки
3) все остальное что внутри метода неважно, тот кто будет его править или там дебажить - ему по любому нада будет разбираться в каждой строчке а тогда уже пофиг какое форматирование
Показывает. Это MVP вызов интерфейса основного представления.т.е. сам крутит message loop?
т.е. речь о том, что если автор не вставляет пустые строки, то больше вероятность, что он пишет тяжелый для понимания код, не имеющий явно записанной внутренней логики.Почему эта вероятность выше, если он их не вставляет и ниже, если вставляет? Что если я разделяю действия коментариями, с чего бы код был при этом более тяжёлый? В твоём же примере вместо пустых строк (или я согласен, вместе с ними) можно поставить твои же коментарии, которые ты написал ниже в топике.
В твоём же примере вместо пустых строк (или я согласен, вместе с ними) можно поставить твои же коментарии, которые ты написал ниже в топике.а нахера? код станет тяжелее для просмотра (больше символов а полезной информации в таких комментариях - 0
т.е. сам крутит message loop?Я тебя понял. Первый message loop появится в момент логина. То есть метод логина отобразит и форму, и диалог. То есть логика разбиений там реально завязана на знание, что представления реализуются в виде Windows Forms? Тогда надо отделить пустой строкой ещё и DoLogin. А когда будет прикручена web морда, то переформатировать код ещё раз.
а нахера? код станет тяжелее для просмотра (больше символов а полезной информации в таких комментариях - 0Отлично. А в пустых строках, что, её больше 0?
Отлично. А в пустых строках, что, её больше 0?конечно, больше.
сходу, даже не всматриваясь - четко видно, что есть отдельные независимые части
сходу, даже не всматриваясь - четко видно, что есть отдельные независимые частиАга. А если всмотреться, то получится, что зависимые.
Ага. А если всмотреться, то получится, что зависимые.ну блин
весь код зависимый
ну блинНу блин. Сейчас в этом топике чётко видно: начал читать чужой код в 4 строки. Из-за пустых строк, на которые должна была возлагаться логика какого-то разделения, он сделал ошибочный вывод о том, что происходит во время выполнения метода. Таким образом, более читаемым приведённый мною код не стал.
весь код зависимый
// проверка условий для вызоваЕбануться!
if (disposed)
throw new ObjectDisposedException("cannot invoke methods on a disposed service proxy");
if (method == AUTHORIZE_METHOD)
throw new InvalidOperationException("the Authorize method must not be called explicitly");
// вызываем метод, пока обрабатываются исключения
....
И это ты, пишущий тело ифа не в строчке условия, не ставя при этом фигурных скобок - ещё что-то говоришь о code style?
попробуй код без единой пустой строки прочитать без подсветки синтаксиса
Ебануться!Ебануться!
И это ты, пишущий тело ифа не в строчке условия, не ставя при этом фигурных скобок - ещё что-то говоришь о code style?
Это я, чей code style был принят новой компанией Давида Яна для разработки коробочного продукта, релиз которого сегодня обслуживает десятки клиентов, говорю о code style.
для разработки коробочного продуктаКак продукт называется? Буду знать, чем нельзя пользоваться.
ептить. кто принимал твой код-стайл?
он сделал ошибочный вывод о том, что происходит во время выполнения метода.не надо делать подмены понятий
выводов я не делал, я только приводил модель рассуждений программиста, который писал этот код.
выводов я не делал, я только приводил модель рассуждений программиста, который писал этот код.Я согласен, что для выводов ты бы посмотрел код поглубже. Но модель рассуждений ты понял неправильно. Так каким образом пустые строки тебе тут помогли?
Так каким образом пустые строки тебе тут помогли?помогли понять, что автор хотел показать - что вот тут он делает что-то одно, а вот тут что-то другое.
че, ты ко мне пристал с требованием точного ответа на основе 4 строк?
может тебе по этим 4 строчкам проанализировать за сколько программу стоит продавать?
как я по твоему могу, видя только 4 строки, не зная ни проекта, ни даже языка, не видя ни разу программиста, не видя code style - могу сказать точно, что именно имел ввиду в данном случае автор.
в таких случаях, часто даже автор не сможет ответить точно, что именно он хотел выделить, но вот ответить, что у него есть ощущение, что это что-то отдельное - всегда может
помогли понять, что автор хотел показать - что вот тут он делает что-то одно, а вот тут что-то другое.Я бы это понял просто посмотрев на имена методов.
че, ты ко мне пристал с требованием точного ответа на основе 4 строк?Я ни к кому не приставал. Я просто вижу, что пустые строки одного программиста не имеют ничего общего с тем, как их поймёт другой программист. Можно вернуться к первому вопросу: нафига они нужны?
Можно вернуться к первому вопросу: нафига они нужны?ты уже ответил на вопросы: зачем нужны методы и комментарии?
а также на вопрос: зачем нужно ставить пробелы вокруг знаков операций?
ты уже ответил на вопросы: зачем нужны методы и комментарии?Не путай принципиально разные вещи. Реальная польза тех же коментариев описана в сотнях книжек, можно я воздержусь от цитирования их текста сюда? Что касается пустых строк, то их необхоидмость нигде не обоснована. Кроме того, если взять реальные code style разных компаний, то раздел о коментариях там найти можно почти всегда. А вот раздела о пустых строках внутри методов обычно нет.
а также на вопрос: зачем нужно ставить пробелы вокруг знаков операций?Да мне, если честно, пофигу на это всё. Я не рассматриваю код с точки зрения студентов без опыта работы. Обоснования необходимости пустых строк в данной теме нет. Думаю, что я получил ответ на вопрос, который меня волновал.
А вот раздела о пустых строках внутри методов обычно нет.тогда мне тебя жаль.
ты просто выполняешь то, что считается правильным, не понимая сути.
если бы ты действительно понял - зачем нужны методы, ты бы понял - и зачем нужно разбиение методов на части, и даже зачем желательны пробелы вокруг знаков.
ps
для mike-а мне лень рассказывать откуда это все берется, если кому-то еще интересно, то тогда попытаюсь подвести базу под важность всего перечисленного.
мне как студенту по сути без опыта нормальной работы это интересно.
У меня конечно есть определенные соображения на эту тему, но если расскажешь, с удовольствием вникну
У меня конечно есть определенные соображения на эту тему, но если расскажешь, с удовольствием вникну
если бы ты действительно понял - зачем нужны методы, ты бы понял - и зачем нужно разбиение методов на части, и даже зачем желательны пробелы вокруг знаков.Если бы ты действительно понял, что такое методы, ты бы понял, почему разбиение их на части с помощью пустых строк бессмысленно.
В этой теме все факты говорят именно об этом.
Если бы ты действительно понял, что такое методы, ты бы понял, почему разбиение их на части с помощью пустых строк бессмысленно.кстати, ты сейчас о каком понимании метода говоришь?:
1. это минимальная единица кода, которая доступна для выполнения внутри готового приложения
2. это инструмент повторного использования кода и устранения дублирования
3. это инструмент для повышения читабельности, понимания и структурности кода
4. это инструмент для выражения отдельной цельной мысли автора
5. это функция или процедура, привязанная к объекту
6. это инструмент для выражения действий над данными
7. это инструмент для посылки и обработки сообщения от объекта к объекту
кстати, ты сейчас о каком понимании метода говоришь?:Я говорю об общем понимании.
Я говорю об общем понимании.есть такая закономерность, чем больше человек в речи использует кванторов: все, всё, общее, обычный, нормальный и т.д. - тем меньше человек понимает о чем идет речь.
т.к. именно за такими общими словами скрывается неспособность автора выразить свое личное мировозрение.
То есть, ты не осилил даже список пониманий, который тут привёл ?
т.к. именно за такими общими словами скрывается неспособность автора выразить свое личное мировозрение.Я не могу понять, что ты мне тут в итоге втираешь? Что я не умею программировать из-за того, что не вижу логики в пустых строках внутри методов? Или ты считаешь, что привёл какие-то аргументы, кроме абстрактного блаблабла, так красиво, разные действия, блаблабла. Конкретнее, пожалуйста. Потому что лично для меня, чем меньше человек приводит аргументов по теме, и чем чаще он пытается тему сменить, тем меньше он понимает, о чём идёт речь.
для начала следующие предпосылки:
1. Первично, что код - это штука, с помощью которой автор(программист) рассказывает другому человеку, как по его мнению правильнее решать данную задачу, а уже вторично - что это еще и рассказ машине.
2. люди разные, и программисты к удивлению тоже. у кого память хорошая, у кого-то плохая, кто-то быстро читает, кто-то медленнее, кто-то схватывает слету, кому-то надо подумать и т.д.
3. основной принцип осмысления человеком окружающего мира (в том числе, и чужого кода) следующий: взяли кусочек, разобрали его, построили в голове упрощенную модельку этого кусочка, поехали дальше.
4. люди в среднем одновременно оперируют только 3-7 понятиями, и забывают предыдущую информацию буквально за секунды
несмотря на то, что в программисты идут, в первую очередь, люди, которые могут одновременно оперировать 173 понятиями, и которые помнят всё, что было начиная с 9 месяцев до начала их рождения, при написании кода надо учитывать:
этот код будет осмысляться другим человеком,
человек будет пытаться построить свою модель написанного кода,
этот человек быстро забывает и оперирует малым числом понятий.
именно из этого последовательно выросли:
1. разбиение кода на процедуры
2. запрет на goto
3. один оператор на строке
4. что код внутри блока должен быть сдвинуть относительно обрамляющего блока
5. отдельная часть кода должна влазить в монитор без необходимости скролинга
6. нет явным числам в коде, только через константы
7. названия длинные и по сути(черт! забыл правильный термин); нет - сокращениям и абревиатурам
7. разбиение кода на функции без side эффектов
8. разбиение кода на модули
9. разбиение кода на объекты/компоненты
10. запрет на static переменные
11. понятие "код - дурно пахнет"
12. появление метрики связность и метрики связанность
13. необходимость писать закрывающей фигурной скобки под открывающей
14. метрики на кол-во строк в метода, кол-во методов в объекте и т.д.
15. необходимость расстановки пробелов около знаков
16. необходимость разбиение метода на части
все это направленно на то, чтобы можно было двигаться следующим образом:
1. взять большой еще непонятный кусок
2. быстро выделить из него 3-7 подчастей
3. каждую подчасть разобрать отдельно(по этому же алгоритму) и сформировать свою упрощенную модель этой части.
4. из полученных моделей скомпоновать свою модель уже всей части -> т.е. получить понимание этой части
тут важно понимать, что при каждом прочтении(при каждом новом осмыслении) модель будет получаться разная, все зависит от того какую задачу мы сейчас решаем, какая модель у нас уже была до этого и т.д.
если, например, ищем определенный баг, то будем пытаться сформулировать модель: как это действие - должно было выполняться, из каких этапов состоит, и на каком этапе все сломалось.
если, например, пытаемся понять как в код добавить новую фичу: то будем пытаться построить модель: закладывал или нет такую модификацию автор в код изначально или нет и т.д.
соответственно:
1. зачем нужно разбиение на методы? чтобы свою модель строить уже на основе готового опыта: какие атомарные операции над этим объектом есть/допустимы
2. зачем нужны четкое название и комментарии на модуль, объект, метод? чтобы можно было не лезть внутрь модуля, объекта, метода, а сразу сформировать свою модель этой сущности
3. почему комментарии внутри метода вредны?
а) это симптом о том, что сам по себе код пишется такой, что он не понятен читающему
b) текста становится больше, и он начинает вываливаться из головы.
причем если код обычно формальный, и на основе его легко строить модели, то комментарии уже неформальные, и в них приходится вчитываться
4. зачем нужны пустые строки(разбиения на части) внутри метода? чтобы можно было при формировании понимания метода выполнить п.2(быстро выделить подчасти) на основе опыта автора
5. зачем нужны пробелы вокруг/после знаков внутри строки? чтобы строку можно было зрительно разбить на отдельные части, которые уже воспринимать по отдельности
1. Первично, что код - это штука, с помощью которой автор(программист) рассказывает другому человеку, как по его мнению правильнее решать данную задачу, а уже вторично - что это еще и рассказ машине.
2. люди разные, и программисты к удивлению тоже. у кого память хорошая, у кого-то плохая, кто-то быстро читает, кто-то медленнее, кто-то схватывает слету, кому-то надо подумать и т.д.
3. основной принцип осмысления человеком окружающего мира (в том числе, и чужого кода) следующий: взяли кусочек, разобрали его, построили в голове упрощенную модельку этого кусочка, поехали дальше.
4. люди в среднем одновременно оперируют только 3-7 понятиями, и забывают предыдущую информацию буквально за секунды
несмотря на то, что в программисты идут, в первую очередь, люди, которые могут одновременно оперировать 173 понятиями, и которые помнят всё, что было начиная с 9 месяцев до начала их рождения, при написании кода надо учитывать:
этот код будет осмысляться другим человеком,
человек будет пытаться построить свою модель написанного кода,
этот человек быстро забывает и оперирует малым числом понятий.
именно из этого последовательно выросли:
1. разбиение кода на процедуры
2. запрет на goto
3. один оператор на строке
4. что код внутри блока должен быть сдвинуть относительно обрамляющего блока
5. отдельная часть кода должна влазить в монитор без необходимости скролинга
6. нет явным числам в коде, только через константы
7. названия длинные и по сути(черт! забыл правильный термин); нет - сокращениям и абревиатурам
7. разбиение кода на функции без side эффектов
8. разбиение кода на модули
9. разбиение кода на объекты/компоненты
10. запрет на static переменные
11. понятие "код - дурно пахнет"
12. появление метрики связность и метрики связанность
13. необходимость писать закрывающей фигурной скобки под открывающей
14. метрики на кол-во строк в метода, кол-во методов в объекте и т.д.
15. необходимость расстановки пробелов около знаков
16. необходимость разбиение метода на части
все это направленно на то, чтобы можно было двигаться следующим образом:
1. взять большой еще непонятный кусок
2. быстро выделить из него 3-7 подчастей
3. каждую подчасть разобрать отдельно(по этому же алгоритму) и сформировать свою упрощенную модель этой части.
4. из полученных моделей скомпоновать свою модель уже всей части -> т.е. получить понимание этой части
тут важно понимать, что при каждом прочтении(при каждом новом осмыслении) модель будет получаться разная, все зависит от того какую задачу мы сейчас решаем, какая модель у нас уже была до этого и т.д.
если, например, ищем определенный баг, то будем пытаться сформулировать модель: как это действие - должно было выполняться, из каких этапов состоит, и на каком этапе все сломалось.
если, например, пытаемся понять как в код добавить новую фичу: то будем пытаться построить модель: закладывал или нет такую модификацию автор в код изначально или нет и т.д.
соответственно:
1. зачем нужно разбиение на методы? чтобы свою модель строить уже на основе готового опыта: какие атомарные операции над этим объектом есть/допустимы
2. зачем нужны четкое название и комментарии на модуль, объект, метод? чтобы можно было не лезть внутрь модуля, объекта, метода, а сразу сформировать свою модель этой сущности
3. почему комментарии внутри метода вредны?
а) это симптом о том, что сам по себе код пишется такой, что он не понятен читающему
b) текста становится больше, и он начинает вываливаться из головы.
причем если код обычно формальный, и на основе его легко строить модели, то комментарии уже неформальные, и в них приходится вчитываться
4. зачем нужны пустые строки(разбиения на части) внутри метода? чтобы можно было при формировании понимания метода выполнить п.2(быстро выделить подчасти) на основе опыта автора
5. зачем нужны пробелы вокруг/после знаков внутри строки? чтобы строку можно было зрительно разбить на отдельные части, которые уже воспринимать по отдельности
Что я не умею программировать из-за того, что не вижу логики в пустых строках внутри методов?я думаю ты хорошо программируешь, потому что все что я здесь говорил никакого отношения к самому программированию не имеет.
потому что - да, компилятору пофигу - сколько и где стоит пустых строк
оно только имеет отношению к тому: насколько твой код быстро понятен сторонним людям.
оно только имеет отношению к тому: насколько твой код быстро понятен сторонним людям.То есть если я скажу, что читаю некоментированный код с пустыми строками в методах дольше, чем код без пустых строк в методах, то какой вывод нужно будет сделать из этого?
То есть если я скажу, что читаю некоментированный код с пустыми строками в методах дольше, чем код без пустых строк в методах, то какой вывод нужно будет сделать из этого?например, привычка, отсутствие навыка.
ты можешь себя отрефлексировать и сказать: почему одно быстрее для тебя, чем другое?
ты можешь себя отрефлексировать и сказать: почему одно быстрее для тебя, чем другое?Могу. Я долгое время использовал пустые строки. Потом, когда я начал читать книжки и статьи по нашей тематике, перестал их использовать. Потому что они для меня потеряли всякий смысл. Когда я читаю код, то не выделяю строки или выражения по отдельности, не выделяю какие-то куски логики внутри методов, ровно как не выделяю отдельные методы классов при изучении их интерфейсов.
По-моему, ты перегибаешь палку. Не всегда есть целесообразность бить на методы.
Ну, скажем, есть балк-код уи интерфейса, где я делаю че-нить простое-уникальное с полями формочки например. Дергаю два-три сеттера у одного элемента, потом у второго.
Ну можно конечно выделить это в два отдельных метода, не спорю. Но имхо бессмысленно, из пушки по воробьям. Читаемость это только снизит.
Поэтому я бы ограничился переносом строки и забил. Станет в этом месте не 4 строчки, а 24 - тогда уже можно будет подумать о рефакторинге.
Ну, скажем, есть балк-код уи интерфейса, где я делаю че-нить простое-уникальное с полями формочки например. Дергаю два-три сеттера у одного элемента, потом у второго.
Ну можно конечно выделить это в два отдельных метода, не спорю. Но имхо бессмысленно, из пушки по воробьям. Читаемость это только снизит.
Поэтому я бы ограничился переносом строки и забил. Станет в этом месте не 4 строчки, а 24 - тогда уже можно будет подумать о рефакторинге.
Поэтому я бы ограничился переносом строки и забил.Ага, а я бы ограничился одним методом без переноса строк.
Ага, а я бы ограничился одним методом без переноса строк.Тоже вариант, но на мой вкус децл менее читаемый =)
Можно вернуться к первому вопросу: нафига они нужны?показать, что связность между операциями внутри одной части выше, чем связность между операциями из разных частей.
показать, что связность между операциями внутри одной части выше, чем связность между операциями из разных частей.О как загнул, пришлось втыкать. Объясни мне, часто у тебя в коде в одном методе слабо связанные операции? И, как я уже спросил во втором посте в этой теме, как ты это определяешь? Теперь вернулись к началу, покатились по теме и снова закончили вопросом: нафига нужны пустые строки?...
Я тоже могу аргументировать разными, скажем так, понятиями. Например, можно сказать, что чем меньше пустых строк в методах, тем они лучше с точки зрения ООП. А если программиста заставлять писать методы без пустых строк, то это будет стимулировать его к написанию правильных методов, а не простыней на несколько экранов.
Объясни мне, часто у тебя в коде в одном методе слабо связанные операции?в целом, постоянно.
метод же лишь связывает операции тем, что их надо выполнить вместе, но в тоже время, эти операции могут быть развязаны:
1. по виду действия(например, трассировка и само действие)
2. по объекту к которому эти действия приложены (например, одна часть лезет в базу, другая модифицирует gui)
3. по влиянию на окружение(например, есть хорошее правило - модифицироваться объект должен только в самом конце метода, после того как уже все было сделано)
и т.д.
в целом, постоянно.Да, тогда постоянно. Только в тех терминах, которые каждый программист выдумает для себя сам. Мы об этом уже говорили в этой ветке, и я не вижу, как это помогает другому программисту читать код.
спасибо. прочитал. ниче нового правда (и слава богу!) не узнал. Но хоть вспомнил кратко и структурированно
Действительно, майк начинает превращаться в пенартура, лол.
Чувак, ты, когда обычный текст на русском языке пишешь, руководствуешься каким-нибудь кодинг стайлом при разбиении его на абзацы, а также вставлении дополнительных пустых строк между абзацами? Есть ли у тебя какое-нибудь чётко-алгоритмическое описание того, в каких случаях следует одно предложение разбить на несколько?
Думаю, нет. Потому что невозможно это формализовать, потому что формализация относится к _синтаксису_, а разбиение текста на абзацы и предложения отражает его семантическую структуру as subjectively perceived автором.
"Вначале мы делаем это. Потом мы делаем это, это и это. Потом ещё это" — невозможно исходя из синтаксиса обосновать, почему я написал это всё именно так. Ну, вот так я это у себя в голове представлял, вот так я расставил пустые строки (то есть точки). Причём если я завтра этот код буду перечитывать, я вполне могу механически удалить какие-нибудь и добавить какие-нибудь другие пустые строки, если теперь мой поток мысли структурирован несколько иначе.
Твоё возражение насчёт "если у тебя "вот это, это и это" хочет логически объединиться в один блок, то нужно вынести его в отдельную процедуру" совершенно мимо, по-моему: разделение кода на процедуры основывается не столько на выполнении одной задачи, сколько на ограниченности используемой части общего состояния. Ну, в смысле, что если у тебя есть "x = 10; x = x + 1; x = x * 2" (ужасно тупой пример, но, надеюсь, проиллюстрирует поинт то ты можешь этот кусок вынести в отдельную функцию, принимающую x в качестве параметра - тогда глядя на неё ты поймёшь, что она, скорее всего, ничего больше непредсказуемого не использует. Если же у тебя есть кусок кода "x = x + 1; y = y + 2; z = z + 3", то выносить его в отдельную процедуру, принимающую x, у и z совершенно без понта. А вот выделить пустыми строками, типа что тут мы что-то логически связанное делаем, очень приятно.
Короче, можешь ещё вот с какой стороны подумать: 95% coding style можно проэнфорсить на уровне компилятора. Переменные называть так-то, скобки ставить так-то, всё такое. Потому что кодингстайл - он про синтаксис. Не надо пытаться в него запихнуть то, для описания чего он принципиально не предназначен.
Чувак, ты, когда обычный текст на русском языке пишешь, руководствуешься каким-нибудь кодинг стайлом при разбиении его на абзацы, а также вставлении дополнительных пустых строк между абзацами? Есть ли у тебя какое-нибудь чётко-алгоритмическое описание того, в каких случаях следует одно предложение разбить на несколько?
Думаю, нет. Потому что невозможно это формализовать, потому что формализация относится к _синтаксису_, а разбиение текста на абзацы и предложения отражает его семантическую структуру as subjectively perceived автором.
"Вначале мы делаем это. Потом мы делаем это, это и это. Потом ещё это" — невозможно исходя из синтаксиса обосновать, почему я написал это всё именно так. Ну, вот так я это у себя в голове представлял, вот так я расставил пустые строки (то есть точки). Причём если я завтра этот код буду перечитывать, я вполне могу механически удалить какие-нибудь и добавить какие-нибудь другие пустые строки, если теперь мой поток мысли структурирован несколько иначе.
Твоё возражение насчёт "если у тебя "вот это, это и это" хочет логически объединиться в один блок, то нужно вынести его в отдельную процедуру" совершенно мимо, по-моему: разделение кода на процедуры основывается не столько на выполнении одной задачи, сколько на ограниченности используемой части общего состояния. Ну, в смысле, что если у тебя есть "x = 10; x = x + 1; x = x * 2" (ужасно тупой пример, но, надеюсь, проиллюстрирует поинт то ты можешь этот кусок вынести в отдельную функцию, принимающую x в качестве параметра - тогда глядя на неё ты поймёшь, что она, скорее всего, ничего больше непредсказуемого не использует. Если же у тебя есть кусок кода "x = x + 1; y = y + 2; z = z + 3", то выносить его в отдельную процедуру, принимающую x, у и z совершенно без понта. А вот выделить пустыми строками, типа что тут мы что-то логически связанное делаем, очень приятно.
Короче, можешь ещё вот с какой стороны подумать: 95% coding style можно проэнфорсить на уровне компилятора. Переменные называть так-то, скобки ставить так-то, всё такое. Потому что кодингстайл - он про синтаксис. Не надо пытаться в него запихнуть то, для описания чего он принципиально не предназначен.
лучше с точки зрения ООПКстати немного оффтопа.
Собеседовал я значится программистов, и многие говорят про ООП что-нибудь в духе: "Да, я там-то и там-то кодил, правда ООП там было мало, но я стараюсь и обязательно буду его использовать".
Я: "А что в нем такого особенного и зачем оно?"
Он: "Эээ..."
Ну, вот так я это у себя в голове представлял, вот так я расставил пустые строки (то есть точки).А я вот так их не расставил. И не тратил времени ни сегодня, ни завтра на то, чтобы перерасставить. Могу я после этого считать, что ты совершил бессмысленное действие? Или я должен при просмотре твоего кода дополнительно тратить время на понимание логики пустых строк?
Не стоит делать ошибочного вывода о том, что я не понимаю, что лично тебе надо было поставить пустые строки. Понимаю, но именно с той позиции, что это надо было только тебе. Не стоит объяснять мне очевидных вещей, которые уже озвучены в теме. Ты это очень любишь.
Потому что кодингстайл - он про синтаксис
Это все давно поняли, кто читал тему, а не гневно думал только о том, что "он посягнул на святое!". Просто я выбрал неудачное название темы. Но видишь, нашлись и те, кто считает пустые строки настолько необходимыми, что начали теоретически доказывать их полезность.
Я: "А что в нем такого особенного и зачем оно?"Ну как же, судя по форуму у нас полно грамотных разработчиков. Хоть кто-то тебе хотя бы про наследование-полиморфизм-инкапсуляцию должен был рассказать.
Он: "Эээ..."
Или я должен при просмотре твоего кода дополнительно тратить время на понимание логики пустых строк?Тут уже кучу раз аналогию проводили.
Когда ты книжку читаешь, ты тратишь время на понимание логики разбивки на предложения, абзацы, главы? Или просто читаешь?
А если бы вся книжка была одним большим предложением, тебе легче было бы воспринимать этот текст?
Тут уже кучу раз аналогию проводили.Ты заделался Капитаном Очевидность? Ясное дело, что тратить время никто не должен и не будет. И это не является плюсом в пользу пустых строк.
Когда ты книжку читаешь, ты тратишь время на понимание логики разбивки на предложения, абзацы, главы? Или просто читаешь?
А если бы вся книжка была одним большим предложением, тебе легче было бы воспринимать этот текст?
Одним предложением набор обозримых методов не является по факту.
Ясное дело, что тратить время никто не должен и не будетТратить время на что?
Одним предложением набор обозримых методов не является по факту.Мне казалось, тут идёт речь о содержимом одного метода, а не о наборе методов. Пустые строки в содержимом метода - как точки в тексте.
Тратить время на что?Пост перечитай. До просветления. Вот эту часть диалога:
Когда ты книжку читаешь, ты тратишь время на понимание логики разбивки на предложения, абзацы, главы? Или просто читаешь?
--------------------------------------------------------------------------------
Ты заделался Капитаном Очевидность? Ясное дело, что тратить время никто не должен и не будет.
Мне казалось, тут идёт речь о содержимом одного метода, а не о наборе методов. Пустые строки в содержимом метода - как точки в тексте.Если у тебя методы по количеству имеющих смысл символов размером с абзацы в книжке, то тебе стоит почитать про структурное программирование.
Если у тебя методы по количеству имеющих смысл символов размером с абзацы в книжкеПонимаешь, кода может быть много, может быть - очень много. Это "очень много" кода, в общем-то, относится к одному и тому же классу.
У тебя есть выбор - либо у тебя в одном классе будет сто методов, из них 90 - приватные и используются только в одном месте; это, по-моему, только усложнит восприятие в те же десять раз. Либо методов - десять, но в каждом из них относительно много кода, описывающего то, что мы делаем. Я не говорю, что большие методы - хорошо, их надо избегать, где это действительно неоправданно - но не стоит и говорить "ага, есть большой метод - значит, весь код говно, выкинуть нахуй". Сразу видно, что ты не имел дела с серьёзными вещами. Да и твой code-style это подтверждает - ты дажене понимаешь, что твой код с ифом оформлен как последнее говно, с ним отвратительно иметь дело, первый же заметивший это говно расставит там фигурные скобки или сделает тело в той же строчке, где условие; а незаметивший - немного изменит, и всё сломается. Такое ощущение, что ты вообще никогда не работал в команде, что сейчас у тебя первый такой опыт, и ты впервые видишь код, который писался не для компилятора, а для человека.
Кроме того, даже короткие абзацы имеет смысл разбивать на предложения, если эти предложения довольно слабо связаны - читается лучше. Примеров в этом треде было достаточно.
А мерять символы - вообще идиотизм. Вспомнить только всякие fgetsscv, где каждая буква наполнена смыслом, а в целом - хуй поймёшь, что оно означает; были бы там вместо букв слова - символов было бы больше, но читаемость бы повысилась, удивительно?
Вообще, в этом треде уже тысячу раз всё разжевали. Если ты не можешь понять даже разжёванные аргументы - дальнейшее продолжение обсуждения бессмысленно, ни к чему это не приведёт. Остаётся только надеяться, что ты когда-нибудь подрастёшь, перестанешь писать говнокод, и поймёшь, зачем нужны пустые строки; в этом треде уже всё сказали.
Или я должен при просмотре твоего кода дополнительно тратить время на понимание логики пустых строк?Ох, чувак, ты же главного не понимаешь. Тебе _не нужно_ понимать их логику. Ещё раз, тебе какой текст легче читать, разбитый на абзацы или сплошняком идущий? Я думаю, приятнее читать разбитый, всё-таки. По крайней мере, если разбивал на абзацы (то есть писал вообще) его вменяемый человек. А если писал невменяемый, то неинтуитивное разбиение на абзацы будет последней твоей проблемой, я гарантирую это, и в случае кода то же самое.
Попытка записать в кодинг-стайлз рекомендации по расстановке пустых строк приблизительно так же осмысленна, как фраза "следует писать понятный код". Ну, потому что ничего другого про расстановку пустых строк написать нельзя, "они должны повышать понятность кода", всё.
Да, конечно, есть люди, которые пишут непонятный код и/или расставляют пустые строки так, что они наоборот мешают плавному восприятию структуры программы. Причём это всё неалгоритмизируемо — либо ты читаешь код и он понятен и красив, как проза Хэмингуэя, либо нет, отличить одно от другого формально ты не можешь, и никакие формальные правила "избегайте предложений длиннее семи слов" нифига не помогут. Более того, возможно найдётся человек (типа тебя которому красивейше оформленный код покажется запутанным, потому что он зачем-то начнёт искать логику в пунктуации (в том смысле, в каком это слово используется по отношению к текстам на естественных языках, то есть в расстановке пустых строк в нашем случае вместо того, чтобы feel da flow. Но это совершенно не повод отказываться от этой самой пунктуации.
Короче. Пустые строки в шарпопроге необходимы ровно в той же степени, в какой в тексте необходимо разбиение на абзацы, выделение некоторых слов курсивом, полужирным шрифтом, КАПСОМ етс. Да, можно обойтись без. Да, неумелое использование этого всего может привести к понижению читаемости. Да, алгоритмизировать это всё невозможно. So fucking what?
Да тут всё это сказали уже по десять раз
Не доходит до него, и всё тут.
Не доходит до него, и всё тут.
> Понимаю, но именно с той позиции, что это надо было только тебе.
В том то и дело что это надо как раз не ему а тем кто будет это читать пусть например 95% людей могут читать нормально текст
без знаков препинании так вот предлагается их вставить во первых для оставшихся 5% а во вторых для 90% людей из первых 95% которым от этого
упростится восприятие текста даже если я сам разницы не вижу как то так так уж получилось что ты попал в 5% людей одинаково воспринимающих текст
со значками и текст без знаков но скорее всего в твоей команде будут люди придерживающиеся иного мнения про удобочитаемость вот для них и надо
В том то и дело что это надо как раз не ему а тем кто будет это читать пусть например 95% людей могут читать нормально текст
без знаков препинании так вот предлагается их вставить во первых для оставшихся 5% а во вторых для 90% людей из первых 95% которым от этого
упростится восприятие текста даже если я сам разницы не вижу как то так так уж получилось что ты попал в 5% людей одинаково воспринимающих текст
со значками и текст без знаков но скорее всего в твоей команде будут люди придерживающиеся иного мнения про удобочитаемость вот для них и надо
Upd
> Не путай принципиально разные вещи. Реальная польза тех же коментариев описана в сотнях книжек, можно я воздержусь от цитирования их текста сюда? > Что касается пустых строк, то их необхоидмость нигде не обоснована. Кроме того, если взять реальные code style разных компаний, то раздел о
> коментариях там найти можно почти всегда. А вот раздела о пустых строках внутри методов обычно нет.
Sun-овские CodeConventions раздел 8.1
> Не путай принципиально разные вещи. Реальная польза тех же коментариев описана в сотнях книжек, можно я воздержусь от цитирования их текста сюда? > Что касается пустых строк, то их необхоидмость нигде не обоснована. Кроме того, если взять реальные code style разных компаний, то раздел о
> коментариях там найти можно почти всегда. А вот раздела о пустых строках внутри методов обычно нет.
Sun-овские CodeConventions раздел 8.1
Слушай, меня иногда удивляет, что ты приходишь в тему и пишешь длинный пост, весьма существенно повторяя всё, что сказали до тебя. Я, в отличие от некоторых, читаю что пишут собеседники и не игнорирую это. И резюмировать это всё в одном посте мне не надо, спасибо.
Я думаю, приятнее читать разбитый, всё-таки. По крайней мере, если разбивал на абзацы (то есть писал вообще) его вменяемый человек.В среднем количество информации даже в одном методе намного меньше количества информации в абзаце. Поэтому лично я не вижу проблемы читать методы целиком.
Попытка записать в кодинг-стайлз рекомендации по расстановке пустых строк приблизительно так же осмысленна, как фраза "следует писать понятный код". Ну, потому что ничего другого про расстановку пустых строк написать нельзя, "они должны повышать понятность кода", всё.В этой теме я уже сказал, что было не совсем верно написать слова code style в заголовке. Возможно, эту часть диалога случайно снесли отсюда. Я не собирался записывать в code style что либо о пустых строках внутри методов. Тема не об этом.
Тебе что в лоб, что по лбу.
В этой теме каждый кроме тебя понимает, зачем нужно деление кода внутри метода на блоки. Ну просто удобно это делать коментами или пустыми строчками. Нет другого механизма в программировании.
Вот нахера сгребать в кучу присваивание значений дюжине переменных, операции над ними ну и, к примеру, вывод? Разбей на три части. Как ты это сделаешь - твои проблемы, всем отписавшимся это удобно делать пустыми строками.
Если у тебя есть пунктик, что количество строк кода должно быть как можно меньше, мне тебя искренне жаль, сам такой был когда-то
В этой теме каждый кроме тебя понимает, зачем нужно деление кода внутри метода на блоки. Ну просто удобно это делать коментами или пустыми строчками. Нет другого механизма в программировании.
Вот нахера сгребать в кучу присваивание значений дюжине переменных, операции над ними ну и, к примеру, вывод? Разбей на три части. Как ты это сделаешь - твои проблемы, всем отписавшимся это удобно делать пустыми строками.
Если у тебя есть пунктик, что количество строк кода должно быть как можно меньше, мне тебя искренне жаль, сам такой был когда-то
Первое - это попытка добавить ...
Второе - я не могу понять, зачем нужны пустые строки? Вот, например, такой код:
А зачем ты здесь использовал пустую строку?
Или вот здесь:
Если бы ты действительно понял, что такое методы, ты бы понял, почему разбиение их на части с помощью пустых строк бессмысленно.
В этой теме все факты говорят именно об этом.
Тебе что в лоб, что по лбу.Ага, давайте меня сожгём на костре за отступничество. И во время этого акта пусть каждый повторяет то, что в этой теме уже написали, и что было мною прочитано, понято и принято к сведению.
Оставить комментарий
kokoc88
Я не могу понять двух вещей в форматировании кода на языках типа C#/Java.Первое - это попытка добавить какой-то смысл в имя переменной. Например, использовать camel case underscore для полей класса и просто camel case для локальных переменных. Для меня вполне естественным является, например, рефакторинг типа make local variable или introduce field. Кроме того, я привык к классам, содержащим обозримое количество кода. И поэтому не помню ошибок, связанных с тем, что я вдруг забыл, что переменная локальная. Какие у вас мысли по этому поводу, и почему?
Второе - я не могу понять, зачем нужны пустые строки? Вот, например, такой код:
Каким образом программист определяет, что здесь нужно две пустые строки? Почему их две? Почему не три? Каким образом пустой строкой можно разделить логику метода? Если хочется, чтобы код был более читаемым и понятным, надо ставить коментарии, а не пустые строки.