Здравствуйте, BishopMorton, Вы писали:

[]

в той ветке под стилем понималось не наименование переменных и тп, а то, что человек тупо не знает, что внутри цикла можно написать return, вместо for, если есть возможность, нужно пользовать foreach, условную переменную (там вроде i) трогать лучше в одном месте, if/else лучше заменить на тернарный ?: и тп

Здравствуйте, BishopMorton, Вы писали:


BM>Пусть ребята которые составляют стандарты языков, соберутся и в следующей версии стандарта определят стиль программирования на этом языке, на уровне грамматики языка.

BM>Стандартизация стиля возможна только если не будет альтернативы. Много программистов заменяют while на during? Они этого не делают, так как это просто запрещено, а иначе кто-нибудь точно так писал бы и на форуме появлялись бы новые сообщения о том, что так жить не можно...

Интересно, как на уровне грамматики языка можно запретить

#define during while

Здравствуйте, BishopMorton, Вы писали:

BM>И все — будет стандарт, не будет стилевых войн и разногласий, наступит мир во всем мире.

Это будет полная потеря backward compatibility — нужно будет весь код поправить и еще заревьють. У опечаток есть какая-то вероятность — умножить на кол-во строк в проекте (читай очень большое число) — они гарантировано будут. Нужно проект полность перетестировать. Плюс посчитай нафига это все команде, у которой стандарт уже внедрен и все хорошо и так.

Максимум, что можно вводить, так это на уровне редактора какие-то стили (как для C#), но это вроде и так есть...

K>>реальности это ни сколько не затрудняет чтение когда
BM>Работали когда-нибудь в саппорте, чтобы нужно было много ковыряться в чужом коде?
BM>когда у вас весь код из одних согласных букв состоит, и блин автору их было так жалко, что он старался их экономить и, по возможности, использовать 3, 4 и 5(!) буквенные сочетания...

Было дело. Но может быть в такой ситуации проще в консерватории подправить? Не брать тех кто такой код пишет, например

BM>Я бы даже запретил бы писать функции больше определенного кол-ва строк , чтобы не повадно было 10 страничных монстров городить.

Есть мнение что разбиение длинной функции на кучу более маленьких не всегда добавляет понимаемости.

Здравствуйте, SergeCpp, Вы писали:

SC>...если value будет объектом класса с оператором bool, напишу if( value == false )

Это нехорошо, потому что при беглом просмотре отрицательное условие читается как позитивное...

Здравствуйте, BishopMorton, Вы писали:

BM>Я бы даже запретил бы писать функции больше определенного кол-ва строк , чтобы не повадно было 10 страничных монстров городить.

А если функция генерится каким-нить тулом, то что, такой код тоже запретить копилировать?

Здравствуйте, BishopMorton, Вы писали:

BM>Практически в любом зрелом языке программирования (С++, Java, С#, Python и т.д) проблемы стиля практически решены. Существует набор стандартных стилей кодирования, лучше которых врядли что-нибудь придумают. Но чтобы решить проблему стиля раз и навсегда, нужно внедрить стиль на уровне языка программирования.

Само по себе многообразие стилей, плюс отсутствие в природе хорошего и четкого описания хотя бы одного какого-то стиля, плюс наличия множества поклонников у каждого из популярных стилей и возникающие время от времени священные войны на этот счет говорят как раз, что проблема стиля не решена.

То, что вы предлагаете — это все равно, как в поэзии выбрать какой-то один стиль, стандартизовать его, а все остальные запретить. Для целей графомании это подходит, но настоящая поэзия от этого умрет. Ну не может Бродский писать в том же стиле, что Маяковский, на то он и Бродский

Здравствуйте, BishopMorton, Вы писали:

...

Проблема не столько в компиляторе, сколько в текстовом редакторе. Нормальный редактор вообще не должен позволять печатать свободный текст. Только то, что соответствует синтаксису языка и стилю. При этом он должен скобки печатать сразу парами и нестираемые отступы проставлять. Вообще, даже не важно, в каком виде сохранён файл. При его открытии он должен отображаться выбранным стилем, да и все дела.

> Тут в соседней ветке подняли вопрос обсуждения стиля, человек даже задумался о смене работы из-за этого, и я решил вынести на суд общественности несколько мыслей по этому поводу.
>
> Практически в любом зрелом языке программирования (С++, Java, С#, Python и т.д) проблемы стиля практически решены. Существует набор стандартных стилей кодирования, лучше которых врядли что-нибудь придумают. Но чтобы решить проблему стиля раз и навсегда, нужно внедрить стиль на уровне языка программирования.
>
> Пусть ребята которые составляют стандарты языков, соберутся и в следующей версии стандарта определят стиль программирования на этом языке, на уровне грамматики языка.
> Программы, которые будут писаться без учета требований стандарта по стилю, не будут просто компилироваться, как синтаксически не правильные.
>
> Причем это не должно быть рекомендацией или warning'м, это не должно вообще компилироваться.
> Например:
> for( — не допустимо
> for ( — компилируется
>
> И так далее...

По-моему, такой язык есть. Называется fortran-77. Причем в версии от 90 года 6 пробелов в начале строки уже не требовались.
А вот VB вообще сам пробелы расставляет

Здравствуйте, BishopMorton, Вы писали:

BM>Причем это не должно быть рекомендацией или warning'м, это не должно вообще компилироваться.
BM>И все — будет стандарт, не будет стилевых войн и разногласий, наступит мир во всем мире.

И появятся инструменты, позволяющие писать программистам, как они хотят, и приводящие к этому стандарту перед скармливанием кода компилятору. Примерно, как сейчас некоторые привинчивают препроцессор к C#.

А такие строгие языки уже есть, например IL в бинарном виде. Лишний байт добавил — и кирдык.

Я что-то не понял, вы пытаетесь нам пересказать содержание статьи Кена Арнольда "Стиль есть содержание", или вы действительно её не читали? В таком случае можете ознакомиться с оригиналом здесь. (Вкратце: человек предлагает сделать стиль программирования неотъемлимой частью стандарта языка, т.е. то же самое, что и вы. Написано ровно 4 года назад)

Здравствуйте, nikov, Вы писали:

N>И появятся инструменты, позволяющие писать программистам, как они хотят, и приводящие к этому стандарту перед скармливанием кода компилятору. Примерно, как сейчас некоторые привинчивают препроцессор к C#.

N>А такие строгие языки уже есть, например IL в бинарном виде. Лишний байт добавил — и кирдык. :)

Ничего, NOP'ами нагонят вариаций.

Здравствуйте, SergeCpp, Вы писали:

SC>Знак ! такой маленький, не углядишь порой

Дык, = от == тоже не всегда сразу отличишь!

Я думаю, это должно происходить на уровне редактора, а не на уровне компилятора. Каждый настраивает себе свой стиль, и когда редактор открывает файл, он автоматически приводится к текущему выбранному стилю. Каждый может настроить параметры под себя — как ставить скобки, пробелы и т.п. При чекине файл форматируется настройками по умолчанию.

Здравствуйте, BishopMorton, Вы писали:

BM>И все — будет стандарт, не будет стилевых войн и разногласий, наступит мир во всем мире.

Переходите на Фортран, батенька. И не на Фортран-90, а на Фортран-4 70-х годов прошлого века. Полное торжество вашей идеи. Первые 5 позиций -пусто или метка, 6-я позиция — признак продолжения, 73-80 — для комментария и т.д. Но даже фортранщики этого не выдержали, хотя привыкли к такому изначально.

BM>>Я бы даже запретил бы писать функции больше определенного кол-ва строк , чтобы не повадно было 10 страничных монстров городить.

L>А если функция генерится каким-нить тулом, то что, такой код тоже запретить копилировать?

Если бы у бабущки...

Hi GarryIV

BM>>>Я бы даже запретил бы писать функции больше определенного кол-ва строк , чтобы не повадно было 10 страничных монстров городить.

L>>А если функция генерится каким-нить тулом, то что, такой код тоже запретить копилировать?

GIV>Если бы у бабущки...

А как компилер отличит написанный код от генеренного? Например у нас применяется генератор, код которого вполне может написать даже начинающий программер. Просто этого кода до чертиков. И некоторые функции могут занимать не одну сотню строк.

Видать придется вводить еще одно зарезервированное слово. Типа сей код генерированный. Вот только как запретить его использовать при написании кода руами...

Здравствуйте, GarryIV, Вы писали:


L>>А если функция генерится каким-нить тулом, то что, такой код тоже запретить копилировать?

GIV>Если бы у бабущки...

Не понял мысли (если она была)

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, BishopMorton, Вы писали:

BM>>И все — будет стандарт, не будет стилевых войн и разногласий, наступит мир во всем мире.

PD>Переходите на Фортран, батенька. И не на Фортран-90, а на Фортран-4 70-х годов прошлого века. Полное торжество вашей идеи. Первые 5 позиций -пусто или метка, 6-я позиция — признак продолжения, 73-80 — для комментария и т.д. Но даже фортранщики этого не выдержали, хотя привыкли к такому изначально.

зато какие красивые таблички получались...

You will always get what you always got
  If you always do  what you always did

Здравствуйте, BishopMorton, Вы писали:

BM>по поду стиля в с++ тут примерно одни и те же полиси во всех конторах... поэтому мне интересно, что там вы видете такого особенного, что нельзя стандартизировать.

BM>кто-то пишет мемберы классов с m_, кто-то начиная с _, кто то myvar_, кто-то itsMyVariable

В руби префиксом @ обозначены переменные экземпляра, а @@ — переменные класса.

BM>кто-то опишет void foo(){
BM>а кто-то
BM>void foo()
BM>{

см. Python с его табуляциями, там такого разнообразия нет.