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

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

В этом среднем посте я хочу поделиться с вами набором простых и понятных правил для написания лучшего, красивого, эффективного и наиболее читаемого кода CPP как в среде Windows, так и в среде Linux, с незначительной модификацией кода, поскольку в Linux и Windows есть другой набор. соглашения об именах.

В этой структуре я предоставляю набор правил для следующих сущностей (я дополню его в будущем):

  • Локальная переменная
  • Глобальная переменная
  • Функции
  • Классы
  • Методы
  • Поля
  • Структура
  • Аргументы
  • Объекты
  • Пространства имён
  • Шаблоны

Я назвал это соглашение о кодировании Milad CPP Syntex (MCS) на будущее, ссылаясь на них, а также давая себе шанс поработать над ним для комитета и сообщества CPP.

Переменные

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

В следующем примере это соглашение об именах для переменных показано в Windows (Visual Studio) и Linux (NeoVim):

Поскольку Microsoft использует нотацию Camel для именования собственных API-интерфейсов и переменных ОС Windows, нам также следует использовать эту нотацию. В Linux, в отличие от Windows, существует другой подход к именованию сущностей.

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

Свободно стоящие функции

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

Именование функций и структуры с описательным и самодостаточным именем имеет решающее значение для написания, а также чтения кода CPP как в Windows, так и в ОС Linux.

Однако, поскольку интерфейсы ядра Windows (API или COM-интерфейсы), такие как WriteConsole, называются в стиле Camel, а также символом верхнего регистра в начале их определений, а также функции C, определенные с помощью символа нижнего регистра и коротких описательных имен, таких как wcslen, мы должны использовать аналогичное соглашение с интерфейсами Windows для наших автономных функций, определяемых пользователем.

Таким образом, лучший способ определить автономную функцию в Windows - использовать нотацию Camel с символом верхнего регистра в начале, например PrintMessage в приведенном выше примере.

В отличие от Windows, в Linux лучше определять определяемые пользователем функции строчными буквами и разделять каждое слово подчеркиванием, потому что в Linux все, от интерфейсов POSIX и SUS до библиотек C / C ++, основано на строчных символах, разделении подчеркивания и коротких имена.

Функции (и методы) Аргументы

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

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

То же самое и с Windows, мы должны следовать этому правилу и в Linux. Это делает наш код информативным, самодостаточным и красивым. Теперь мы можем просто прочитать код и интерпретировать его, не путаясь с другими типами сущностей.

Структура и классы

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

Тем не менее, когда мы пишем код cpp с ООП или процедурной парадигмой, нам нужны классы и структуры соответственно.

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

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

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

Также рекомендуется определять экземпляр объекта информационного плана с заглавной буквой O в Windows и o_ в Linux. В следующем примере я определяю класс с той же концепцией, что и вышеупомянутая структура.

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

Однако с помощью этой нотации мы можем понять, что сейчас не является простой пользовательской сущностью. Кроме того, вы должны позаботиться об одной важной концепции именования полей при написании кода на C ++. К сожалению, некоторые программисты используют двойное подчеркивание в начале имени члена своего поля, что на практике приводит к неопределенному поведению, поскольку компилятор использует __ в начале их идентификатора. Итак, мы не должны определять элемент поля с двойным подчеркиванием, потому что:

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

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

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

Шаблоны

Шаблоны - это основа общего программирования, которое предполагает написание кода способом, независимым от какого-либо конкретного типа. Шаблон - это план или формула для создания универсального класса или функции. Контейнеры библиотеки, такие как итераторы и алгоритмы, являются примерами универсального программирования и были разработаны с использованием концепции шаблона.

Однако в большинстве примеров кода, документации и… когда кто-то собирается определить шаблон, он использует ‹typename T› или что-то в этом роде. Но это снижает читаемость исходного кода. Мы должны использовать значимые слова, а не просто T, Tr или…

Кроме того, в Linux мы должны использовать то же соглашение об именах шаблонов для нашего кода. Это делает наш код настолько значимым, насколько это возможно, как если бы мы занимались метапрограммированием.

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