Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
да AVK>2) Если да, то зачем?
затем, что файл с последней строкой без \n не является IMO текстовым —
это в лучшем случае что-то текстоподобное.
P.S. Обычно этот перевод строки за меня вставляет vim.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
Да.
AVK>2) Если да, то зачем?
Удобнее diff'ы смотреть — если что-то добавится, то бывшая последняя строка не будет показана как изменённая.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки? AVK>2) Если да, то зачем?
Предпочитаю ограничители разделителям. Из «общих» соображений: последовательность вида { a; b; c; } всегда проще генерировать, чем последовательность вида (a, b, c). Возможно, поэтому в C# разрешено ставить запятую перед закрывающей фигурной скобкой в enum'ах и непустых списках инициализации.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки? AVK>2) Если да, то зачем?
AVK>P.S. Я в курсе, что не у всех языков C-style синтаксис.
C++ Standard:
If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, the behavior is undefined.
Приветствую, AndrewVK, вы писали:
AVK> 1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
Да
AVK> 2) Если да, то зачем?
Никогда не задумывался, всегда так делал.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
Да.
AVK>2) Если да, то зачем?
а) Потому что иначе компилятор gcc выдает warning, а я всегда стремлюсь, чтобы warning'ов было 0.
б) Чтобы в редакторе FAR было удобнее конец исходника смотреть.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
посмотрел свои исходники java за разные года — с самого начала последняя фигурная скобка у меня является последним символом
посмотрел также исходники pl/sql, там после закрывающей / перевод строки присутствует
AVK>2) Если да, то зачем?
после / в скриптах pl/sql перевод строки нужен, чтобы они могли накатываться через sqlplus
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
да
AVK>2) Если да, то зачем? AVK>P.S. Я в курсе, что не у всех языков C-style синтаксис.
Вот именно поэтому.
Есть языки, которые требуют перевода строки в конце файла.
Легче настроить редактор один раз, чтоб он всегда ставил в конце перевод строки, чем париться на тему, в каком языке можно, а в каком — нельзя.
Плюс диффы, про них Cyberax уже сказал.
Здравствуйте, alexeiz, Вы писали:
A>C++ Standard: A>
A>If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, the behavior is undefined.
Когда-то давно видел компилятор C, незамечавший последнюю }, есди за ней не было перевода строки. С тех пор машинально вставляю этот перевод строки.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
А я ставлю два. Vim сам ставит один, и я еще один добавляю (но не более). Собственно, в vi последний перевод строки не виден и его так просто не удалить, но он, подобно суслику, есть. Так что в некоторых редакторах при некоторых условиях вставка этого перевода строки не является действием, которое нужно особо предпринимать.
AVK>2) Если да, то зачем?
Нравится, когда в конце файла есть полностью пустая строка, на которую можно перейти кнопкой G. Причины тому скорее в области иррационального.
Тоже, кстати, вопрос интересный — если последний байт файла 0x0A, а предпоследний нет (например, скобочка 0x7D), то куда должна ставить курсор команда «перейти на последнюю строчку»? Vim и Emacs разного об этом мнения.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
Нет
AVK>2) Если да, то зачем?
а зачем он там?
Благо давным давно нормальные компиляторы этот архаизм не требуют.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AndrewVK, Вы писали:
AVK>Компиляторы не требуют, а народ вот требует. Потому и интересуюсь.
Ну, вы только не додумайтесь их в автомате сандалить. А то одни требуют, другие не любят. Уж лучше пусть каждый сам решает ставить или нет.
Лично мне по барабану если они там или нет, но если редактор или Решарпер начнет их ставить, то я буду раздражаться, так как инстинктивно не люблю помощь без просьбы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки?
Это как вопрос психиатра "наступаете ли вы на трещины на асфальте?". Понятия не имею, вставляю или нет.
Здравствуйте, alexeiz, Вы писали:
A>C++ Standard: A>
A>If a source file that is not empty does not end in a new-line character, or ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, the behavior is undefined.
В Стандартопроекте, 2.2/1.2:
A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, AndrewVK, Вы писали:
AVK>>1) Вставляете ли вы после последней фигурной скобки в конце файла перевод строки? AVK>>2) Если да, то зачем?
Q>Предпочитаю ограничители разделителям. Из «общих» соображений: последовательность вида { a; b; c; } всегда проще генерировать, чем последовательность вида (a, b, c). Возможно, поэтому в C# разрешено ставить запятую перед закрывающей фигурной скобкой в enum'ах и непустых списках инициализации.
О да. +100.
Как меня задолбало спотыкаться в Erlang'е то на то, что надо добавить запятую, то не добавлять, то добавить ';', то не добавлять...
И в диффах мура — по сути строка не изменена, но добавился после неё новый элемент — дописывай запятую.
Если же все разделители выносить на отдельные строки — читать это станет невозможно.
нэнавыжу
И главное — ничего в синтаксисе не сломается, если переделать на ограничители. Или только пару мелочей подправить. Но не хотят.
Здравствуйте, netch80, Вы писали:
N>Если же все разделители выносить на отдельные строки — читать это станет невозможно. N>нэнавыжу
Да, когда начинают строки с символов пунктуации (выстраивают запятые в линеечку или ещё какие-нибудь геометрические узоры городят) — хочется взять и...
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, netch80, Вы писали:
N>>Если же все разделители выносить на отдельные строки — читать это станет невозможно. N>>нэнавыжу
Q>Да, когда начинают строки с символов пунктуации (выстраивают запятые в линеечку или ещё какие-нибудь геометрические узоры городят) — хочется взять и...
Ну к этому я более терпим — потому что это было стандартом синтаксиса Фортрана (у оператора продолжения — в 6-й позиции не пробел, туда ставили всякие звёздочки и запятые. Хотя в современных языках это выглядит ужасно. Но главное — что оно не решает проблему — ну заменили запятую в конце на запятую в начале, всё равно строка испорчена.
Здравствуйте, netch80, Вы писали:
Q>>Да, когда начинают строки с символов пунктуации (выстраивают запятые в линеечку или ещё какие-нибудь геометрические узоры городят) — хочется взять и...
N>Ну к этому я более терпим — потому что это было стандартом синтаксиса Фортрана (у оператора продолжения — в 6-й позиции не пробел, туда ставили всякие звёздочки и запятые. Хотя в современных языках это выглядит ужасно. Но главное — что оно не решает проблему — ну заменили запятую в конце на запятую в начале, всё равно строка испорчена.
Ну, в контексте диффов и «порченных строк» (впрочем, меня это никогда особо не беспокоило), если строка начинается с запятой, то добавление после неё следующей строки не приводит к изменению текущей.
Здравствуйте, Qbit86, Вы писали:
Q>>>Да, когда начинают строки с символов пунктуации (выстраивают запятые в линеечку или ещё какие-нибудь геометрические узоры городят) — хочется взять и...
N>>Ну к этому я более терпим — потому что это было стандартом синтаксиса Фортрана (у оператора продолжения — в 6-й позиции не пробел, туда ставили всякие звёздочки и запятые. Хотя в современных языках это выглядит ужасно. Но главное — что оно не решает проблему — ну заменили запятую в конце на запятую в начале, всё равно строка испорчена.
Q>Ну, в контексте диффов и «порченных строк» (впрочем, меня это никогда особо не беспокоило), если строка начинается с запятой, то добавление после неё следующей строки не приводит к изменению текущей.
Зато если убрать все перед ней — то придётся изменить. Пустые запятые в начале — даже ты вряд ли потерпишь.:))
А порченые диффы распыляют внимание. Иногда это таки важно.
Здравствуйте, netch80, Вы писали:
N>Зато если убрать все перед ней — то придётся изменить. Пустые запятые в начале — даже ты вряд ли потерпишь.:))
С другой стороны, «пустые запятые» в начале в общем случае могут быть не запятыми, как в случае символа «или» при паттерн-матчинге. Там он полне уместен, и работает как ограничитель (слева), но может быть и разделителем (между), если список петтернов короткий. Профит!