OberonCore

Давно уже заметил у Илья Ермакова и некоторых других необычную манеру именования переменных. Сейчас обратил на это внимание вновь, просматривая коды из раздела wiki на сайте. На мой взгляд, слишком короткие имена переменных ухудшают читабельность кода. В чём причина такого подхода?
Чтобы не быть голословным, вот пример даже не самой плохой в этом смысле функции:

Почему бы не писать таким образом, чтобы названия переменных отражали их смысл? Тем более для примеров\учебных пособий. Для и для работы очень полезно. Вот, например, та же функция ( имена могли быть поняты неверно, просто чтобы сравнить два варианта ):

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

Согласен с Андреем. Чрезмерное сокращение имён переменных вижу повсеместно в исходниках на Обероне. С именами процедур и типами обычно всё в порядке. Локальные переменные простительны, если используются стандартные буквы (i - INTEGER, s - строка и т.п.). Но параметры процедур и поля записей в одну-две буквы не способствуют чтению, это точно. Я всегда для них использую одно или два полных слова, иногда сокращение (prev вместо previous, res вместо result и т.п.).

Речь не о понятности.

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

Автокомплит решает две задачи: вспомнить название и ввести без ошибок с минимумом нажатий. Если уж мы пытаемся угадать причину краткости имён, то к автокомплиту, вроде бы, имеет отношение только вторая, а первая относится к общей культуре именования (общепринятые типичные имена).

Если уж гадать о причинах, то помимо автокомплита можно назвать чувствительность к регистру. Получается, что нужно не только набирать вручную, но и набирать без ошибок. Но всё это мне кажется сильно второстепенным. На первом месте - культура работы. Тут, мне кажется, существенную роль играет то, что читает человек, осваивающий систему. Как кто усвоил, так и сам потом пишет, и так далее по цепочке. А вы заглядывали в ОС Оберон? Да что там ОС, достаточно посмотреть виртовские исходники компилятора, которые без словаря (т.е. его учебного курса) читать невозможно.

Ну и, конечно, модульность играет роль. Если пространство имён глобальное, как в Си, то будешь подробно выписывать идентификаторы, с префиксами и суффиксами - хоть есть у тебя автокомплит, хоть нету его. А если каждый модуль изолирован, и импорт квалифицирован, то всё можно именовать одинаково: Init + Do.

Это не только мой стиль, он когда-то сформировался под влиянием исходных текстов Блэкбокса.

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

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

В общем, такой стиль как раз верно расставляет акценты и помогает воспринимать исходный текст.

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

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

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

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

Не могу себе представить нормально написанную процедуру, в которой употребление коротких имён вместо длинных снизило бы понятность.
Что там вообще понимать-то, внутри процедуры?

Только циклы, навороченные не по базовым схемам и без инвариантов.

Долгое время не решался высказать это же "фи". Поражает "читаемостью" как виртовский, так и ББ-ный код. Казалось бы, уж они точно должны быть теми примерами, на которые стоит равняться. Линейка виртовских языков славится читаемостью, но эта читаемость подобным стилем для не-авторов рубится по корню. То же самое, кстати, касается математики и физики. Сокращение умножения до записи двух идентификаторов слитно поставило жирный запрет на возможность использования более понятных имён сущностей (а также необходимость использовать греческие буквы, кирилицу и иные извращения). Во время обучения те страницы формул, что вводят в дрожь, могли бы казаться вполне ясным и осмысленным псевдокодом.
Возвращаясь к переменным, нисколько не затрудняет использование идентификаторов вроде: KeyPreprocessFunc, ItemsAreObjects, MiddleItemHash, NumNotProcessedNodes. Что может быть понятно стороннему читателю, когда эти имена превратятся в PrFn, IAreObjs, mh, npNodes? Фактически, нужно загружать временную память информацией расшифровки каждой переменной (обязательно глянуть VAR-секцию, все типы, а также, возможно и объявление этих типов в модуле). Потом на каждом шаге усилием воли восстанавливать r до Reader, mh до MiddleItemHash, IAreObjs до ItemsAreObjects и т.д. В итоге мозг трещит по швам и не хочет в упор переваривать цикл с тремя операторами на одной строке с мини-именами переменных.

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

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

1) Такие короткие обозначения сопровождаются объявлениями типов, которые обычно длинные и читабельные. В недлинной процедуре этого достаточно.

2) Такие обозначения обычно стандартные и общие для целой серии процедур в одном модуле, и даже для нескольких модулей. p для страниц, i, n, k для стандартных счетчиков и т.п.

На одной строке налепить больше одной инструкции -- часто сильно помогает глазу.
Плюс экономия пространства экрана.
Обмен значений двух переменных.
Прицепить в конце строки вспомогательный ASSERT.
Короткий IF x < a THEN x := a END или простенький поиск-WHILE.
и т.п.

Хотя у Вирта в книжках бывает чуть чрезмерная плотность кода.
Но это просто привычка со времен маленьких экранов.

Так что филиппики AV в этом пункте -- в сущности, сотрясения воздуха.
( Надеюсь, "филиппики" не так обидны, как "истерики" )

Локальные переменные процедуры убирающейся на полэкрана не превратятся в PrFn, IAreObjs, mh, npNodes, они превратятся во что-то из множества: q, w, e, r, t, u, i, p, a, s, d, f, g, h, j, k, z, x, c, v, b, n, m.

Для локальных переменных (область действия которых полностью на виду) стараюсь использовать однобуквенные обозначения.

У кого есть желание выработать единый стандарт оформления кода для проектов на КП (если это ещё не сделано)?
Думаю, будет полезно для общих КП-проектов: примеры кода, модули для BB, правки в BB и т.д.
Вот мой вариант ( касается только именования переменных ):

1) Названия всех переменных и функций составляются слитно, каждое новое слово присоединяется к текущему без разделителя. Переменные модуля пишутся с маленькой буквы: itemCount, releaseMemory, directory

2) Экспортируемые переменные носят не сокращённые имена, начинаются с большой буквы: Maps, Page, IgnoreCase

3) Поля записей и параметры функции пишутся без сокращений, с маленькой буквы: PROCEDURE (VAR list: List) AddItem(IN data : Data), RECORD sessionID: LONGINT; count: INTEGER END
Название можно сократить, если оно используется в смысле индекса, например t

4) Локальные переменные пишутся с маленькой буквы, и сокращаются. Чем меньше область видимости, тем короче название.

5) Для индексов резервируются переменные: i, j, k, m, n, t

6) Для длины и количества резервируются переменные length и сount соответственно

7) Константы именуются заглавными буквами, слова разделяются _: PAGE_SIZE

С учётом вышеописанного, исходная функция выглядела бы так:

Какие у кого идеи?

В ББ есть документ по стилю: Docu\BB-Rules.odc.

Ужас!

А откуда эта функция взялась? Укажите, пж, URL.

Согласен
Документ по стилю не помню, но кажется там не было ничего касающегося именования. Вечером посмотрю.


http://oberoncore.ru/wiki/blackbox/ex/history_models

Вы не забывайте что в книге Вирта алгоритмы повыше повседневного уровня. И код ББ в местах системного характера - тоже.
Тут просто в голове у Вас корреляция, наверное, получилась: надо-разбираться-с-алгоритмом-сразу-не-понятно + ах-да-тут-ещё-переменные-короткие-какой-ужас.

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