Стиль программирования

← →
cybervisor (2004-03-08 16:40) [0]

Подскажите как реализовать

Разработка программного комплекса СТИЛЬ ПРОГРАММИРОВАНИЯ.
реализующий функции:
-чтение исходного текста проги на паскале
-анализ проги на предмет соблюдения стиля -->>особенно это!!!
-выдача сообщений о нарушении стиля
-запись правильной проги в новый файл
-просмотр исходного и нового файла одновременно на экране(экран разделен на 2 окна)

← →
TUser © (2004-03-08 16:43) [1]

Труднее всего будет экран на 2 окна разделить ...

← →
Nous Mellon © (2004-03-08 17:11) [2]

> cybervisor (08.03.04 16:40)

Может лучше заняться ИИ.. Попроще будет :)))

← →
reticon © (2004-03-08 17:18) [3]

ИИ... это типа делать "Ку"? ;-)))

← →
Romkin © (2004-03-08 17:20) [4]

Именно. Стиль обычно в процентах оценивается.

← →
Nous Mellon © (2004-03-08 17:22) [5]

> ИИ... это типа делать "Ку"? ;-)))

Нет. АйКу :)

← →
Юрий Зотов © (2004-03-08 17:32) [6]

Задача, в общем-то, вполне решаемая (обычный парсер + заранее определенные правила того, что считать хорошим и плохим стилем). Только очень многое зависит от входного языка. Скажем, если требуется поддержка полного Object Pascal, то повозиться придется изрядно, а если на входе какое-то подмножество языка, то все становится проще.

← →
Romkin © (2004-03-08 17:38) [7]

Не совсем согласен, что повозиться придется. Керниган, Ритчи. В их книге по С введен рейтинг стиля, причем на основе простой статистики, комментарии только распознаются вроде...

← →
Romkin © (2004-03-08 17:45) [8]

Тьфу, ну я и путаюсь. Берри, Микинз. Язык С. Введение для программистов.
Оттуда: Есть таблица (Критерий, вес в %%, диапазон), например:
Длина модуля 15% 10-20 непустых строк Длина идентификатора 14% 5-10 символов Процент строк-примечаний 12% 15-25% от общего кол-ва Процент отступов... и тд
Согласен, парсинг нужен, но не сказать, чтобы уж слишком сложный :)

← →
Юрий Зотов © (2004-03-08 17:57) [9]

> Romkin © (08.03.04 17:45) [8]

> Согласен, парсинг нужен, но не сказать, чтобы уж слишком
> сложный :)

При наличии полного и точного формального определения языка - да. А если его еще придется составлять, то для полного Object Pascal (да еще в его современной Delphi-реализации) - это еще та задачка.

← →
TUser © (2004-03-08 18:00) [10]

[8] - это и есть оценка стиля программирования. Надо бы еще оценивать многое другое, например отсутствие глобальных переменных с неосмысленными названиями, типа i:integer. Это входит в понятие стиль программирования, я думаю.

← →
Romkin © (2004-03-08 18:03) [11]

Это от критериёв правильности зависит. Можно просто считать отступы, пустые строки и расстояния между блоками - все через пробелы в начале строки. Уже, кстати, неплохой критерий получается.
Главная сложность - в определении правильности. Кроме экспертной оценки для набора статистики я ничего не вижу.

← →
Romkin © (2004-03-08 18:07) [12]

TUser © (08.03.04 18:00) [10]
Глобальная - да... Согласен. А вот для локальной имя i - самое оно!
Сложность в оценке, я уже сказал. Для меня лучше всего, например, почти полное отсутствие глобальных переменных в модуле :)

← →
Юрий Зотов © (2004-03-08 18:16) [13]

> Длина идентификатора 14%

IMHO, вес сильно завышен. Куда важнее совершенно иные критерии, которые даже не указаны. И они куда труднее учитываются. Те же глобальные переменные, например (особенно, ссылки). А как оценить потокобезопасность? Минимальное использование ресурсов, надежность и своевременность их освобождения?

И т.д. На этом фоне какую-то там "длину идентификатора" можно хоть воооще не рассматривать - это будет уже мелочь, а не 14%.

← →
Romkin © (2004-03-08 18:34) [14]

Я привел критерии для С, там это не завышено (имхо).
Разумеется, для Паскаля (объектного) должны быть другие критерии с другим весом. Какие и с каким - как я сказал, должны решать эксперты. Проблема, как я уже сказал, в том, чтобы, во-первых, найти эксперта, а во-вторых, заставить его сказать, что именно ему не нравиться в этом стиле.
Потокобезопасность и остальное - имхо, это уже не стиль, это оценка умения. Согласись, прога может быть написана очень красиво, но с таааакими ошибками в алгоритме! (Я так точно могу :)))
"Минимальное использование ресурсов, надежность и своевременность их освобождения" точно не стиль. Это уже из области анализа правильности программ. Это даже не на порядок сложнее, это NP задача уже

← →
Romkin © (2004-03-08 18:38) [15]

Вот простой пример: просит кто-то глянуть исходник...
Я говорю: Феее, сделай сначала отступы нормально, по стандарту! Сделал... Феее... У тебя что-то процедуры длинные. Сокращай... Феее... А где комментарии?!! и тд. Это - стиль.
А содержимое - оформи, тогда и посмотрю, что тут у тебя с потоками, с выделением памяти...

← →
Romkin © (2004-03-08 18:42) [16]

Я помню, как сам выл о правилах оформления курсовых, диплома и тд. И только потом понял: это - надо. Занятой человек не будет вникать в каракули.
Уверен, что если просто сделать статистику по форуму, то вопрос, в котором исходный текст в хорошем стиле, получит наибольшее количество ответов (какой бы глупой прога не была!), чем вопрос с плохим стилем

← →
Юрий Зотов © (2004-03-08 18:47) [17]

> Romkin

Вот мы и пришли к вопросу ГЛАВНОМУ - что есть стиль?
:о)

Угу. На мой взгляд, стиль - соблюдение условностей по оформлению кода. С полным отрывом от его содержания.
Например:
finction TMyClass.isTruth(ATruth: string): boolean; var Truth: TMyTruth; i: integer; begin Truth := TMyTruth.Create; Result := True; //Предполагаем, что все в порядке for i := 1 to length(ATruth) do if not Truth.isTruth(ATruth[i]) then begin Result := False; //Увы, ожидание не оправдалось Break; end; Truth.Free; end;
Первое, что в голову стукнулось. Стиль - идеален на 100% (имхо). А вот код - с недочетом :(

> Romkin © (08.03.04 18:42) [16]

Согласен. Вот буквально сейчас на "Основной" висит вопрос, в который я даже и не стал вникать после того, как только взглянул на код. Судя по сабжу, вопрос не должен быть сложным, но разбирать полсотни строк грязи? Увольте.

> Юрий Зотов © (08.03.04 19:02) [19]
Вот именно! Я все время пишу так, что оценка стиля программы будет где-то выше 70% (имхо), но это же не уберегает меня от ошибок? Для нахождения ляпсов есть свои струменты, тот же отладчик. Но он никоим образом не следит за стилем. Пофиг ему :)
Определение: Стиль - то, что не оказывает влияния на правильность программы, но, вместе с тем, стандартизирует ее исходные тексты и облегчает понимание сторонним программистом.
Годится?

> Romkin © (08.03.04 19:18) [20]

Да, это один из вариантов. С точки зрения сабжа, пожалуй, только такое определение и можно принять.

Но я все же вкладываю в понятие "стиль" нечто гораздо большее, чем наименования переменных, форматирование и комментирование кода. Ведь говорят же "безопасный стиль"? Говорят. Есть такое понятие. И если я в модуле каждой формы вижу глобальную переменную, которую среда создает по умолчанию, то я это считаю ОЧЕНЬ плохим стилем. И если вижу хотя бы один варнинг или даже хинт компилятора - то это тоже очень плохой стиль. И когда глобальные константы раскиданы по куче разных модулей - то это тоже очень плохой стиль. И т.д., и.т.п.

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

← →
cybervisor (2004-03-08 20:37) [22]

Господа!!! Подскажите по существу. не заморачивайтесь.
Прога должна быть немного проще.
Ставит пробелы и тп. Просто делает "красивый" исходник.

> И когда глобальные константы раскиданы по куче разных модулей
> - то это тоже очень плохой стиль.

Т.е. константы SQL_NULL_HSTMT и CLASS_HTMLDocument надо будет в один модуль собрать?

Эксперт, приводящий код с соответствии с заданным стилем, c исходиками http://www.dow.wau.nl/aew/delforexp.htm

> DiamondShark © (08.03.04 20:38) [23]

Не обязательно в один, можно группировать по смыслу или области применения. Но группировать все равно надо. В Delphi есть Windows, Messages, Consts и пр. - вот пример. И если этого не делать, то каждый новый пришедший в проект программист (да и не новый тоже) обязательно начнет такие константы в своих модулях дублировать.

То же относится, например, и к типам (особенно, перечислимым), к типам событий и пр. Не зря ведь в Delphi все же появился модуль Types.

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

Стиль программирования Найти похожие ветки