naming conventions что это

Правила именования для стиля кода

Правило именования включает три следующих компонента:

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

Общий синтаксис

Чтобы определить правило именования, группу символов или стиль именования, задайте одно или несколько свойств с помощью следующего синтаксиса:

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

Порядок свойств не имеет значения.

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

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

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

Свойства правила именования

Чтобы правило вступило в силу, должны быть указаны все свойства правила именования.

Примечания.

Свойства группы символов

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

Примечания.

Свойства стиля именования

Стиль именования определяет соглашения, которые будут применяться к правилу. Например:

Для стиля именования можно задать следующие свойства:

Примечания.

Порядок правил

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

Если вы используете более раннюю версию Visual Studio, чем Visual Studio 2019 версии 16.2, правила именования в файле EditorConfig должны быть упорядочены от более конкретных к более общим. Применяться будет только первое обнаруженное правило. Но при наличии множества свойств правил с одним и тем же именем приоритет будет иметь последнее обнаруженное свойство с таким именем. См. подробнее об иерархии файлов и приоритетности.

Стили именования по умолчанию

Если вы не укажете никаких пользовательских правил именования, применяются следующие стили по умолчанию:

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

Для интерфейсов со специальными возможностями по умолчанию используется стиль именования Pascal с обязательным префиксом I.

Идентификатор правила кода: IDE1006 (Naming rule violation)

Пример

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

Источник

naming convention

Смотреть что такое «naming convention» в других словарях:

Naming convention — For conventions governing Wikipedia article names, see Wikipedia:Naming conventions. A naming convention is a convention for naming things. The intent is to allow useful information to be deduced from the names based on regularities. For instance … Wikipedia

naming convention — noun A collection of rules followed by a set of names which allow users to deduce useful information, based on the names character sequence and knowledge of the rules followed; such as Manhattans East West streets being called Streets and its… … Wiktionary

Naming convention (programming) — In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types and functions etc. in source code and documentation. Reasons for using a naming convention … Wikipedia

Product naming convention — A product naming convention is a method of naming products so that customers and industry can understand or identify a product quickly. Use of numbers and letters can help sort out sections or parts of a name. Special characters should be omitted … Wikipedia

Option naming convention — In financial markets, an option naming convention is a method of identifying which of many possible options is being quoted or traded. Contents 1 Standard convention 1.1 Expiration Month Codes 1.2 Strike Price Codes … Wikipedia

Leszynski naming convention — The Leszynski naming convention (or LNC) is a variant of Hungarian notation popularized by consultant Stan Leszynski specifically for use with Microsoft Access development. [ [http://msdn.microsoft.com/archive/default.asp?url=/archive/en… … Wikipedia

Uniform Naming Convention — Universal Naming Convention En informatique, Universal Naming Convention ou Uniform Naming Convention abrégé UNC est une convention sur une manière de définir l’adresse d’une ressource sur un réseau, mise en œuvre par Microsoft Windows. Plutôt… … Wikipédia en Français

Uniform Naming Convention — (auch Universal Naming Convention, kurz UNC) wird weitgehend als Standard zur Bezeichnung von Adressen freigegebener Ressourcen in einem Rechnernetz genutzt. Die UNC Adresse stellt einen Netzwerkpfad dar, über den man Ressourcen anderer Rechner… … Deutsch Wikipedia

Universal Naming Convention — En informatique, Universal Naming Convention ou Uniform Naming Convention abrégé UNC est une convention sur une manière de définir l’adresse d’une ressource sur un réseau, mise en œuvre par Microsoft Windows. Plutôt que de spécifier une lettre de … Wikipédia en Français

Universal Naming Convention — Uniform Naming Convention (auch Universal Naming Convention, kurz UNC) wird weitgehend als Standard zur Bezeichnung von Adressen freigegebener Ressourcen in einem Rechnernetz genutzt. Die UNC Adresse stellt einen Netzwerkpfad dar, über den man… … Deutsch Wikipedia

Uniform Naming Convention — Uniform Naming Convention, UNC … Universal-Lexikon

Источник

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

СОДЕРЖАНИЕ

Потенциальные преимущества

Некоторые из потенциальных преимуществ, которые можно получить, приняв соглашение об именах, включают следующее:

Вызовы

Читаемость

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

является синтаксически правильна, его цель не очевидна. Сравните это с:

что подразумевает намерение и значение исходного кода, по крайней мере, для тех, кто знаком с контекстом утверждения.

Эксперименты показывают, что стиль идентификатора влияет на отзыв и точность, а знакомство со стилем ускоряет отзыв.

Общие элементы

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

Длина идентификаторов

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

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

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

Краткость в программировании частично объясняется:

Регистр букв и цифры

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

Идентификаторы из нескольких слов

Слова, разделенные разделителями

Слова, разделенные буквами

Примеры форматов идентификаторов, состоящих из нескольких слов

Метаданные и гибридные соглашения

Венгерская нотация

Позиционное обозначение

Такое соглашение все еще активно используется в мэйнфреймах, зависящих от JCL, а также встречается в стиле MS-DOS 8.3 (максимум восемь символов с разделителем точки, за которым следует трехсимвольный тип файла).

Составная схема слов (OF Language)

«Язык OF» IBM был задокументирован в руководстве по IMS ( системе управления информацией ).

В нем подробно описана словесная схема PRIME-MODIFIER-CLASS, которая состоит из таких имен, как «CUST-ACT-NO» для обозначения «номера счета клиента».

Слова PRIME предназначались для обозначения основных «сущностей», представляющих интерес для системы.

Слова МОДИФИКАТОР использовались для дополнительного уточнения, уточнения и удобочитаемости.

В идеале слова CLASS были бы очень коротким списком типов данных, относящихся к конкретному приложению. Общие слова CLASS могут быть: NO (номер), ID (идентификатор), TXT (текст), AMT (сумма), QTY (количество), FL (флаг), CD (код), W (работа) и т. Д. На практике доступные слова КЛАССА будут списком из менее чем двух дюжин терминов.

Назначение слов CLASS, помимо согласованности, состояло в том, чтобы указать программисту тип данных конкретного поля данных. Перед принятием полей типа BOOLEAN (только два значения) FL (флаг) будет указывать на поле только с двумя возможными значениями.

Конкретные языковые соглашения

ActionScript

В диалектах APL между словами используется дельта (Δ), например PERFΔSQUARE (строчные буквы традиционно отсутствовали в старых версиях APL). Если в названии используются подчеркнутые буквы, то вместо них будет использоваться подчеркиваемая дельта-черта (⍙).

C и C ++

Любое имя идентификатора может начинаться с символа коммерческого предложения ( @ ) без каких-либо изменений в значении. То есть оба factor и @factor относятся к одному и тому же объекту. По соглашению этот префикс используется только в тех случаях, когда идентификатор в противном случае был бы либо зарезервированным ключевым словом (например, for и while ), которое не может использоваться в качестве идентификатора без префикса, либо контекстным ключевым словом (например, from и where ), в котором В некоторых случаях префикс не требуется строго (по крайней мере, не при его объявлении; например, хотя объявление dynamic dynamic; является действительным, это обычно будет восприниматься как dynamic @dynamic; немедленное указание читателю, что последнее является именем переменной).

В Go принято использовать символы подчеркивания MixedCaps или mixedCaps подчеркивания для написания многословных имен. При обращении к структурам или функциям первая буква указывает видимость для внешних пакетов. Если сделать первую букву в верхнем регистре, этот фрагмент кода будет экспортирован, а в нижнем регистре он будет использоваться только в пределах текущей области видимости.

Джава

Имена переменных должны быть короткими, но содержательными. Выбор имени переменной должен быть мнемоническим, то есть предназначенным для указания случайному наблюдателю цели его использования. Следует избегать односимвольных имен переменных, за исключением временных «одноразовых» переменных. Общие имена временных переменных: i, j, k, m и n для целых чисел; c, d и e для символов.

JavaScript

Цель-C

Паскаль, Модула-2 и Оберон

Виртовские языки Паскаль, Модула-2 и Оберон обычно используют идентификаторы Capitalized или UpperCamelCase для программ, модулей, констант, типов и процедур, lowercase или lowerCamelCase идентификаторы для математических констант, переменных, формальных параметров и функций. В то время как некоторые диалекты поддерживают символы подчеркивания и доллара в идентификаторах, регистр змейки и регистр макроса, скорее всего, ограничены использованием в интерфейсах внешнего API.

Рекомендации PHP содержатся в PSR-1 ( стандартная рекомендация PHP 1) и PSR-12. Согласно PSR-1, имена классов должны быть в PascalCase, константы классов должны быть в MACRO_CASE, а имена функций и методов должны быть в camelCase.

Python и Ruby

И Python, и Ruby рекомендуют UpperCamelCase использовать имена классов, CAPITALIZED_WITH_UNDERSCORES константы и lowercase_separated_by_underscores другие имена.

Хотя официального руководства по стилю для R нет, руководство по стилю tidyverse от R-гуру Хэдли Уикхема устанавливает стандарт для большинства пользователей. В этом руководстве рекомендуется избегать использования специальных символов в именах файлов и использовать только цифры, буквы и символы подчеркивания для имен переменных и функций, например fit_models.R.

Ржавчина

Rust рекомендует UpperCamelCase использовать псевдонимы типов и имена вариантов struct, trait, enum и enum, SCREAMING_SNAKE_CASE для констант или статики, а также snake_case для имен переменных, функций и структур.

Быстрый

Начиная с Swift 3.0, были сформулированы четкие инструкции по именованию для языка с целью стандартизации соглашений об именах и объявлениях API для всех сторонних API.

Источник

Общие соглашения об именовании

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

Выбор слов

✔️ Выбирайте для идентификаторов легко читаемые имена.

✔️ Удобочитаемость важнее краткости.

Имя свойства CanScrollHorizontally лучше, чем ScrollableX (неочевидная ссылка на ось X).

❌ НЕ используйте знаки подчеркивания, дефисы и другие символы, не являющиеся буквенно-цифровыми.

❌ НЕ используйте венгерскую нотацию.

❌ ИЗБЕГАЙТЕ использования идентификаторов, совпадающих с ключевыми словами широко используемых языков программирования.

В соответствии с правилом 4 спецификации CLS все соответствующие языки должны предоставлять механизм, который разрешает доступ к именованным элементам, использующим ключевое слово этого языка в качестве идентификатора. Например, в C# в качестве escape-символа используется @. Однако рекомендуется избегать часто встречающихся ключевых слов, поскольку гораздо сложнее использовать метод с escape-последовательностью, чем без нее.

Использование сокращений и акронимов

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

❌ НЕ используйте акронимы, которые не являются широко принятыми, и в целом используется акронимы только при необходимости.

Предотвращение использования имен, связанных с конкретным языком

✔️ Для имен типов используйте семантически содержательные имена, а не ключевые слова, относящиеся к конкретному языку.

✔️ Используйте универсальное имя типа CLR, а не относящееся к конкретному языку имя, в редких случаях, когда у идентификатора нет семантического значения, кроме его типа.

Именование новых версий существующих API

✔️ При создании новых версий существующего API используйте имя, аналогичное старому API.

Это помогает подчеркнуть связь между API.

✔️ Чтобы указать новую версию существующего API, желательно добавлять суффикс, а не префикс.

Это поможет найти нужную информацию при просмотре документации или использовании IntelliSense. Старая версия API будет находиться близко к новым версиям API, так как большинство браузеров и IntelliSense отображают идентификаторы в алфавитном порядке.

✔️ Используйте новый, но понятный идентификатор вместо добавления суффикса или префикса.

✔️ Используйте числовой суффикс, чтобы указать новую версию существующего API, особенно если существующее имя API является единственным понятным именем (например, если оно является отраслевым стандартом) и если добавление любого понятного суффикса (или изменение имени) не представляется возможным.

❌ НЕ используйте суффикс «Ex» (или аналогичный), чтобы отличать идентификатор его от более ранней версии того же API.

✔️ Используйте суффикс «64» при внедрении версий API, которые работают с 64-разрядными целыми числами (длинное целое число), а не с 32-разрядными целыми числами. Этот подход следует применять только в том случае, если существует 32-разрядный API. Не используйте его для новых API, у которых есть только 64-разрядная версия.

Фрагменты: © Корпорация Майкрософт (Microsoft Corporation), 2005, 2009. Все права защищены.

Источник

Именование объектов в Oracle. Взгляд «со стороны»

«Старая песня о главном»

«Стандарты именование объектов БД» и «правила оформления кода» темы не новые. Так или иначе, к вопросу выработки или заимствования таких стандартов и правил приходят все команды разработчиков. При желании в сети можно найти статьи и презентации по данной теме, а так же примеры и шаблоны различных соглашений. Многие из них безусловно полезны, некоторые — практически идеальны, если бы не одна маленькая оговорка: они написаны разработчиками и для разработчиков.

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

В принципе, пожелания по оформлению и именованию у «прикладника» (администратора приложения/технолога) и разработчика на 90 процентов совпадают. Но существуют все же некоторые отличия в восприятии «читателя» и «писателя», о которых я хотел бы поговорить.

Цель данной статьи: выработать свод правил именования объектов баз данных (мне нравится термин Naming Conventions – NC, по аналогии с Code Conventions) для применения командой разработчиков программных продуктов при проектировании информационных систем на базе СУБД Oracle, удовлетворяющий следующим требованиям:

Те, кому лень читать про разные подходы к именованию и продираться через доводы в защиту того или иного подхода, могут просто прокрутить статью до конца, где я привел ссылку на собственный «Oracle NC»-плакат. Там же вы сможете найти другие полезные ссылки по теме топика.

Вы еще здесь? Смогли сдержаться и не начали скроллить? Поздравляю, вам достается специальный бонус: вы можете скачать «Oracle NC»-плакат прямо здесь, не сходя с этого места. Дело в том, что я уже читал свою статью (да-да) и заранее предупреждаю: она громоздка и изобилует малопонятными с первого взгляда врезками-шаблонами. Воспринимать ее будет гораздо проще, имея под рукой все правила и примеры на одном листе.

Все знают, что главное в танке, но не каждый может сдержаться…

Казалось бы, идея выработки NC для проекта в сфере IT лежит на поверхности. Соблюдение требований NC при проектировании и разработке, тоже задача не бог весть. Однако ж, мой опыт работы с решениями от ведущих российских разработчиков на рынке биллинговых систем для телекоммуникационных компаний говорит о том, что культура именования объектов и оформления исходного кода на деле крайне низка. В принципе, все решения, которые по долгу службы были мной изучены, можно поделить на четыре группы:

Общие рекомендации

Начнем с того, о чем следует помнить и чему следовать при разработке под СУБД Oracle:

Честно говоря, в Oracle можно задать регистрозависимое наименование для объекта. Например, вот так:

create table «MyTable» (a number);

Короче, избегайте таких извращений.

Правила именования объектов

Таблицы

В вопросе именования таблиц я почти полностью разделяю точку зрения Билла Коулэма. Разработанный им стандарт исчерпывающ и практически идеален, как для разработчика, так и для «эксплуататора». Я не буду приводить здесь полный перевод, остановлюсь только на основополагающих моментах.

Итак, Коулэм предлагает следующую универсальную форму именования таблицы (фигурные скобки включают обязательные компоненты, а «прямые» скобки – опциональные):

Группа используется для тех же целей: она позволяет группировать сущности, логически связанные между собой (обычно до 20 объектов в группе). Представляет собой так же сокращение в 2-4 символа. Использование системной и логических групп позволяет не только группировать сущности в дереве объектов, но и существенно упрощает разработку и сопровождение системы в целом. Действительно, исчезает необходимость запоминать наименования конкретных объектов, достаточно помнить аббревиатуры модуля и логической группы, а дальше подсказчик кода поможет легко найти необходимый вам объект.

С Наименованием все понятно. Это и есть фактическое название сущности. Билл Коулэм рекомендует использовать единственное число, но лично мне ближе и привычнее множественное (Стивен Ферстайн, привет!). И Стивен и Билл советуют избегать сокращений в наименованиях сущностей. Исключения — слова длиннее 8 символов.

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

В отдельный класс Коулэм выделяет таблицы, посредством которых реализуется взаимосвязь «многие-ко-многим». Для таких таблиц он предлагает следующий шаблон именования:

В большинстве проектов, с которыми я сталкивался, для таких таблиц-ассоциаций разработчики использовали «значащие» имена. Сам я использую шаблон:

Код таблицы в данном случае представляет собой сокращенное наименование таблицы, которая участвует в связке (2-4 символа). Например, таблица, хранящая связи студентов (STUDENTS), посещающих лекции преподавателей (TEACHERS) в данном стандарте будет называться STUD_TCHR. Да, на первый взгляд выглядит отталкивающе, но со временем понимаешь удобство: с первого взгляда классифицируешь таблицу как «связку» (благодаря использованию кодов/аббревиатур вместо полных имен), сразу видишь, какие сущности связываются.

Колонки (столбцы) таблиц

Начнем с ограничений общей длины наименования – старайтесь уложиться в 15 символов (лучше — меньше). Запас до верхнего ограничения вам понадобится для последующего именования ограничений, индексов и столбцов с внешним ключом.
В своих проектах я использую следующий шаблон:

Код таблицы представляет собой сокращенное наименование таблицы, которой принадлежит колонка (2-4 символа). Хоть я и обозначил данный префикс опциональным, я его использую почти для всех столбцов. Исключение – «служебные» столбцы, которые хранят значение неких свойств абстрактной записи любой таблицы, а не свойств конкретного объекта (например, UPDATE_DATE, UPDATE_BY и т.п.).

Наименование столбца говорит само за себя. Отдельно хочется сказать только о правиле формирование наименования для внешнего ключа – оно состоит из кода дочерней таблицы плюс полное наименованием родительского первичного ключа.

Роль – опциональный суффикс. Обращаю внимание, что это тип значения столбца, а не код типа данных этого столбца! Чаще всего я использую следующие роли (типы значений):

Ограничения

Коулэм рекомендует именовать ограничения, используя префикс в виде полного имени таблицы, на которую данное ограничение распространяется. Я считаю такое именование необоснованным расточительством, особенно с учетом общего лимита в 30 символов на длину наименования. Поэтому стараюсь, где возможно использовать Код таблицы вместо полного имени. Таким образом, для первичного ключа получаем:

Здесь и далее префиксы Модуль и Группа ограничения получают в «наследство» от таблицы, с которой они связаны. Это позволяет избежать нарушений уникальности при формировании имен в больших системах, а так же удобно группировать ограничения по модулям.

Для уникального ключа, построенного на одном столбце:

Напоминаю, что шаблон столбца у нас включает Код таблицы. Таким образом, для колонки PRM_CODE таблицы UTL_PARAMS_REF уникальный ключ будет называться UTL_PRM_CODE_UK

Для уникального ключа, построенного на нескольких столбцах:

COMP – в данном случае обозначает COMPOSITE (признак составного ключа), # (порядковый номер) используется если уникальных составных ключей несколько (если честно, я не могу придумать вменяемый пример для такого случая).

Внешний ключ на базе одного столбца:

Так как полное наименование столбца внешнего ключа у нас содержит Коды дочерней и родительской таблиц, то для колонки PVL_PRM_ID таблицы UTL_PARAM_VALUES внешний ключ будет называться UTL_PVL_PRM_ID_FK (ссылается на столбец PRM_ID таблицы UTL_PARAMS_REF)

Внешний ключ, построенный на нескольких столбцах:

Ограничение на уровне столбца:

Ограничение на уровне таблицы:

На просторах Интернета я часто встречал горячие обсуждения необходимости именования ограничения типа NOT NULL. Да, согласен, лениво, но если строго придерживаться концепции, то:

Индексы

Индексы на базе одного столбца:

Я считаю шаблон Коулэма частным случаем и всегда стараюсь перечислить все столбцы (если при этом не нарушается ограничение по длине) в наименовании индекса:

Почему я ограничиваюсь модификатором COMP для ограничений, но стараюсь не использовать его для индексов? Все дело в том, что составные ограничения все-таки являются скорее исключением, чем правилом. Их обычно не очень много, да и сообщение с ошибкой об их нарушении встречаются не очень часто. Другое дело – составные индексы. Во-первых, их просто много. Во-вторых, их часто больше одного на таблицу. И, в третьих, разработчик и администратор приложения работает с ними постоянно, проверяя планы запросов.

Триггеры

В данной статье я рассматриваю только триггеры DML, потому что считаю, что все остальные типы относятся больше к зоне ответственности DBA, а не разработчика. Триггеры я именую по следующим правилам:

Где аббревиатуры B, А, С (BEFORE, AFTER, COMPOUND), определяют «момент» срабатывания триггера; I, U, D (INSERT, UPDATE, DELETE) – событие срабатывания; S (STATEMENT) — определяют «уровень» срабатывания.

Представления

Последовательности

Последовательности я выделяю среди других объектов суффиксом _SEQ и рекомендую именовать по следующему правилу:

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

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

Для примера, последовательность для генерации первичного ключа таблицы INTERNET_LOGINS я назову ILG_SEQ, а последовательность для генерации логина конкретной учетной записи интернет – LOGIN_SEQ.

Синонимы

Синонимы именуются так же, как и объекты, на которые они ссылаются

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

Данный шаблон рекомендует Коулэм. Признак коллекции типа обознается символом Т. Таким образом, тип одиночного объекта всегда имеет суффикс _T, тип коллекции — _TT. Например, UTL_PARAMETER_T, UTL_PARAMETER_TT.

Здесь S обозначает множественное число, а суффикс TYP квалифицирует объект БД как тип. Например, UTL_PARAMETER_TYP, UTL_PARAMETERS_TYP. Это подход мне нравится менее всего, потому что признак коллекции не выделен и глаз за него не цепляется.

В данной нотации, если наименование объекта БД заканчивается на OBJ или TAB, то объект является типом (TAB – коллекция, OBJ – одиночный объект). Например, UTL_PARAMETER_OBJ, UTL_PARAMETERS_TAB

Программные модули

Правила оформления кода программных модулей я хотел бы выделить отдельную статью. Здесь приведу шаблон, предлагаемый Коулэмом. Для пакетов процедур Билл использует следующее правило:

В терминах NC Коулэма Функциональный модификатор (для меня понятнее термин Подгруппа) используется при выделении каких-то функций в отдельный пакет при рефакторинге. Скажем так, это дополнительный уровень логической группы. Например, пакет UTIL содержал функции работы с числами и строками. Его разбили на два: UTIL_NUMBER и UTIL_STRING.

При разработке в PL/SQL специалист постоянно оперирует функциями и процедурами других пакетов. Чтобы код не смотрелся громоздким, я стараюсь избегать ненужного удлинения в наименовании пакетов. Поэтому суффикс _PKG использую только в случаях, когда наименование пакета может совпадать с наименованием другого объекта схемы.

Для отдельных процедур и функций Коулэм рекомендует следующий шаблон:

Под действием понимается глагол (GET, SET, ASSIGN, RUN), под целью – то, что необходимо сделать. Со своей стороны, я стараюсь вообще не использовать процедуры и функции вне пакетов при разработке. Кроме того, те же функции у меня часто группируются по объектам, с которыми они работают, поэтому я обычно использую шаблон

Таким образом, подсказчик кода отлично группирует процедуры по объектам: PARAM_GET, PARAM_SET, PARAM_CHECK и т.п.

Заключение

Как и обещал, привожу ссылку на собственный «Oracle NC»-плакат.
Я, ни в коем случае, не навязываю никому свои правила и стандарты и не настаиваю на их использовании. Я просто считаю наличие NC и соблюдение его требований в команде хорошим стилем — «вежливостью» разработчика к тому, кто будет работать впоследствии с системой.
Удачи вам в ваших проектах.

Источник