2000

Между делом, общее количество рабочего времени, потраченного на проект с момента его начала в 2015 году, перевалило за 2000 часов. Насколько это до фига, я подробно описывал 500 рабочих часов назад.

Об оформлении кода (нотации и не только)

Здравствуйте Андрей Викторович, позвольте вопрос

Я пишу змейку на 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: Извините, что так нагло врываюсь с вопросами в блог, но это для меня очень важно =)

admin аватар

Гыгыгы

Сейчас, пожалуй, задам встречный вопрос, которого вы не ждали. Соглашения об именованиях я бы, возможно, применил другие, но то, что вы тут расписали, допустимо, почему бы и нет, главное — придерживаться единообразия. Меня вот другое беспокоит — откуда это у вас в программе на Паскале такое количество "функций"? Не, ну я бы понял, если бы это была программа на Си, там подпрограммы только функциями и бывают, но Паскаль-то всё-таки не Си.

Отчего-то

Отчего-то привык подпрограммы называть функциями, да, и всё-таки у меня в модулях есть и процедуры, причём подпрограмма из примера cliDrawSnake(...) как раз одна из таких. (а ведь их пожалуй даже большинство)

Вчера я начал переписывать модули (отдельно от первой их версии), придавшись какому-то догматизму по части оформления, уже думал как оно, так или эдак, что лучше читается, а что покажется дурным тоном для стороннего наблюдателя за моим кодом. В едином мнении сам с собой не сошёлся даже xDD

Просто хочу узнать как правильно и структурировано оформлять код, чтобы его мог переварить как я, так и читатель "по ту сторону монитора". Так же предполагал существование каких-нибудь правил или стандартов, на которые можно опираться, но пока пишу чисто интуитивно, стараясь выстроить всё логически красиво.

admin аватар

В программах на

В программах на Паскале, разумеется, и должно быть больше процедур, чем функций. Функции, если их применять правильно, предназначены только для вызова из арифметических выражений и в целом требуются реже (едва ли не на порядок), чем процедуры. А путать их — это основа для сишности головного мозга, которая, на минуточку, не лечится (вообще-то писать на Си можно и нужно, главное — не думать на Си).

Стандартов на эту тему, к счастью, никаких нет, а если бы были, с ними пришлось бы бороться, как и с любыми стандартами. Но если вас интересуют мои рекомендации, то к собственной книжке мне особо даже и добавить нечего. Дальше — только ваш собственный личный опыт.

Спасибо,

Спасибо, наверное я всё же излишне педантичен относительно оформления, обязательно обращусь к вашей книге; раньше я откладывал её из-за того, что видел в содержании глАвы о C и C++ но, думаю, час настал =)

admin аватар

Там есть и

Там есть и главы про Лисп и Пролог, теперь что же, книжку не читать? Сдаётся мне, не читать отдельные главы было бы логичнее.

Ждем,

Ждем, ждем..
Очень хочется уже увидеть перевыпуск!

Надеюсь,

Надеюсь, интервью (если состоится) привлечет ощутимый объем средств на переиздание.

admin аватар

Интервью

Интервью, судя по всему, состоится не скоро, если вообще состоится (чтобы это понять, достаточно почитать в интернете, что сейчас творится в Минске). Я, честно говоря, очень надеюсь, что переиздать книгу удастся раньше, чем выйдет интервью.

Осталось

Осталось немного чтобы сравнять счёт времени до 2021. :-)

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".