2000Mon Jan 4 19:14:42 2021 UTC Между делом, общее количество рабочего времени, потраченного на проект с момента его начала в 2015 году, перевалило за 2000 часов. Насколько это до фига, я подробно описывал 500 рабочих часов назад. 
|
пояснениеВы находитесь на официальном сайте Андрея Викторовича Столярова, автора учебных пособий по программированию и информационным технологиям. Если вы искали сайт замечательного писателя-фантаста Андрея Михайловича Столярова, то вам, к сожалению, не сюда. Андрей Михайлович Столяров в библиотеке Мошкова |
☞ From someone (unverified) Wed Jan 6 21:20:00 2021 UTC
Об оформлении кода (нотации и не только)
Здравствуйте Андрей Викторович, позвольте вопрос
Я пишу змейку на FreePascal с использованием своих знаний из первого тома, так вот, змейку я дописал, и она даже работает =) Только вот проходясь по коду, я понял - что-то меня в нём не устраивает, тут даже несколько ситуаций:
--------------------
А именно, имена функций у меня были написаны с ипользованием нотации snake_case, а имена большинства переменных с использованием camelCase.
Я слышал, что при выборе определённой нотации нужно придерживаться её (скажем camelCase), нужно ли использовать её для всех идентификаторов в коде, или есть какие-либо исключения?
--------------------
--------------------
Я так же разделил всю программу на 8 логических модулей, в одном из которых хранятся значения длины/ширины игрового поля (в виде константы), имена констант я снабдил префиксами модуля:
Сперва так:
PGmax_x (Интуитивно, от слова playground)
Затем исправил на:
pgMaxX (С учётом нотации)
Но мне показалось, что из-за отсутствия подчёркивания идентфикатор неприятно читать, поэтому, возможно, стоит оставить название в виде:
pgMax_x (?)
--------------------
--------------------
Так же, для того, чтобы понимать откуда какая функция пришла, я давал им соответствующие их модулям префиксы:
cliDrawSnake(var snake: snakeBody; var pg: playground)
(Для примера, тут префикс cli, от имени модуля "cli_interface.pas")
Стоит ли так делать?
--------------------
Как быть в подобных случаях?
Или где можно больше почитать об этом?
p/s: Извините, что так нагло врываюсь с вопросами в блог, но это для меня очень важно =)
ответить
Гыгыгы
Сейчас, пожалуй, задам встречный вопрос, которого вы не ждали. Соглашения об именованиях я бы, возможно, применил другие, но то, что вы тут расписали, допустимо, почему бы и нет, главное — придерживаться единообразия. Меня вот другое беспокоит — откуда это у вас в программе на Паскале такое количество "функций"? Не, ну я бы понял, если бы это была программа на Си, там подпрограммы только функциями и бывают, но Паскаль-то всё-таки не Си.
ответить
Отчего-то
Отчего-то привык подпрограммы называть функциями, да, и всё-таки у меня в модулях есть и процедуры, причём подпрограмма из примера cliDrawSnake(...) как раз одна из таких. (а ведь их пожалуй даже большинство)
Вчера я начал переписывать модули (отдельно от первой их версии), придавшись какому-то догматизму по части оформления, уже думал как оно, так или эдак, что лучше читается, а что покажется дурным тоном для стороннего наблюдателя за моим кодом. В едином мнении сам с собой не сошёлся даже xDD
Просто хочу узнать как правильно и структурировано оформлять код, чтобы его мог переварить как я, так и читатель "по ту сторону монитора". Так же предполагал существование каких-нибудь правил или стандартов, на которые можно опираться, но пока пишу чисто интуитивно, стараясь выстроить всё логически красиво.
ответить
В программах на
В программах на Паскале, разумеется, и должно быть больше процедур, чем функций. Функции, если их применять правильно, предназначены только для вызова из арифметических выражений и в целом требуются реже (едва ли не на порядок), чем процедуры. А путать их — это основа для сишности головного мозга, которая, на минуточку, не лечится (вообще-то писать на Си можно и нужно, главное — не думать на Си).
Стандартов на эту тему, к счастью, никаких нет, а если бы были, с ними пришлось бы бороться, как и с любыми стандартами. Но если вас интересуют мои рекомендации, то к собственной книжке мне особо даже и добавить нечего. Дальше — только ваш собственный личный опыт.
ответить
Спасибо,
Спасибо, наверное я всё же излишне педантичен относительно оформления, обязательно обращусь к вашей книге; раньше я откладывал её из-за того, что видел в содержании глАвы о C и C++ но, думаю, час настал =)
ответить
Там есть и
Там есть и главы про Лисп и Пролог, теперь что же, книжку не читать? Сдаётся мне, не читать отдельные главы было бы логичнее.
ответить
☞ From Lucky (unverified) Tue Jan 5 19:34:00 2021 UTC
Ждем,
Ждем, ждем..
Очень хочется уже увидеть перевыпуск!
ответить
Надеюсь,
Надеюсь, интервью (если состоится) привлечет ощутимый объем средств на переиздание.
ответить
Интервью
Интервью, судя по всему, состоится не скоро, если вообще состоится (чтобы это понять, достаточно почитать в интернете, что сейчас творится в Минске). Я, честно говоря, очень надеюсь, что переиздать книгу удастся раньше, чем выйдет интервью.
ответить
☞ From Anonymous (unverified) Mon Jan 4 19:26:00 2021 UTC
Осталось
Осталось немного чтобы сравнять счёт времени до 2021. :-)
ответить