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

Слова не в начальной форме могут быть использованы только в том случае, если они используются МНОГО раз и при этом во ВСЕХ местах — одинаково.

Следствие: в качестве последнего слова имени может быть использовано только общепринятое сокращение (или неначальная форма), которое ВЕЗДЕ (и много раз) в программе используется именно в таком варианте. Если сокращение используется редко, то предпочтительнее использовать начальную форму слова.

Пример 1. StrToFloat — плохое имя. В ряде языков программирования есть зарезервированное слово "String". В таком случае получается, что в некоторых случаях к строкам обращаемся по полному имени, а в некоторых — по сокращению. Однако сокращение "Str" — общепринятое в системах программирования фирмы "Borland". При использовании этих систем, но не в SQL-запросах, такое сокращение резонно использовать, и имя StrToFloat становится хорошим именем.

Пример 2. StringToFloat — хорошее имя (если не учитывать наличие лишнего слова "То", но "То" хорошо показывает, что это имя процедуры конвертора типов).

Пример 3. mp_pagelist — хорошее имя, если в группе "mp" много имен или это сокращение используется в таком же написании и таком же смысле большое количество раз в других именах (mp — сокращение от "main page").

Пример 4. PASSPORT_PASSWORD_LENGTH_MIN — хорошее имя, сокращение в конце — общепринятое и везде в системе используется именно в таком варианте написания.

Пример 5. TPassportPrivileges — плохое имя для таблицы, в которой хранится список привилегий. Очевидно, что в таблице хранится много всяких привилегий, и множественное число в данном случае излишне.

Пример 6. TPassport_Privilege — хорошее имя, однако если бы не велась речь о базах данных, префикс "T" соответствовал бы типу, а не переменной.

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

Случаи, в которых использование префиксов оправдано:

• если это не имена переменных, а имена типов переменных, можно использовать префикс "T";

• если имена ваших сущностей будут перемешиваться с посторонними именами;

• в случае локальных имен.

Имена, используемые в ограниченном контексте, могут быть очень короткими. Традиционно имена i и j используются для обозначения счетчиков, p и q — для указателей, s — для строковых, а ch — для литерных переменных. Эти традиционные кратчайшие имена могут соответствовать префиксам, поясняющим тип переменных.

Пример 1. is_passport_privilege_valid — плохое имя. Префикс в глобальном имени излишен.

Пример 2. passport_privilege_valid — хорошее имя.

Пример 3. i_order — хорошее имя для поля в таблице, указывающее на порядок чего-либо. Префикс "i" характеризует тип целый.

Дополнительные рекомендации по составлению имен:

• не начинайте и не заканчивайте имена символом подчеркивания;

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

• не следует в одной и той же программе использовать имена, различающиеся лишь написанием букв — строчной или прописной;

• в зависимости от возможностей языка программирования можно разделять части имен символом подчеркивания или написанием с большой буквы очередной части имени;

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

Ряд понимаемых трудно имен следует тщательно комментировать. Такой комментарий лучше приводить справа от описания имени.

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

Рефакторинг (от англ. refactoring) — оптимизация, улучшение реализации программы без изменения ее функциональности.

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

Применительно к именам под рефакторингом понимается изменение имен таким образом, чтобы они соответствовали новым требованиям. Имена — это очень важная часть программы. Многие программисты склонны преуменьшать значимость имен.

Непонятные имена — это нечитаемая программа, а нечитаемую программу тяжело сопровождать.

Рассмотрим случаи, в которых может потребоваться рефакторинг имен:

Случай 1 — изменение правил. Можно составить разные правила образования имен и следовать сначала одним правилам, потом, уточнив эти правила, следовать другим. Неизменным должно оставаться только одно правило: все имена в проекте должны быть построены по одним правилам.

Случай 2 — частичный рефакторинг имен. Если по каким-либо причинам изменили правила составления имен, то следует обновить все имена, не подходящие под новые правила.

Случай 3 — невозможность однозначного предсказания будущего. Любой проект развивается. На этапе создания может оказаться, что спроектированная структура не полна или сначала предполагалась одна структура, а затем стала очевидной другая, более предпочтительная структура.

Случай 4 — рефакторинг имен, на ваш взгляд, не нужен: вы уже заканчиваете работу над проектом, не планируете в будущем его поддерживать и вам все равно, что о вас подумают люди, которым придется разбираться в вашем коде.

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

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

Область машиностроения наряду с такими "кубиками", как болты, гайки, оперирует множеством нетиповых элементов. Например, левое крыло и правое крыло автомобиля хотя и очень похожи друг на друга, но не могут быть взаимозаменяемыми и могут использоваться лишь в конкретной модели автомобиля. В области машиностроения значительные усилия проектировщиков расходуются на проектирование элементов. Количество элементов, из которых состоят получающиеся конструкции, обычно не превышает нескольких сотен.

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

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

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