Именование функций, методов, указателей, переменных, массивов и т. Д. В C ++ - PullRequest
Новая
       34

Именование функций, методов, указателей, переменных, массивов и т. Д. В C ++

1 голос
/ 03 апреля 2009

Хорошо, я делаю какой-то проект с несколькими друзьями, и мне нужен какой-то стандарт для именования вещей в c ++. У кого-нибудь есть какая-нибудь хорошая схема именования для c ++, которая хорошо продумана и не сделана за 10 минут.

Например, int * house должен называться int * house_p, поэтому, когда кто-то читает код, ему не нужно постоянно прокручивать, задаваясь вопросом, является ли объект указателем, массивом, матрицей или чем-то еще ...

Опубликуйте свои хорошо продуманные схемы именования, которые вы используете!

Ответы [ 8 ]

20 голосов
/ 03 апреля 2009

Пример, int * house должен быть назван int * house_p, так что когда кто-то читает код, ему не нужно прокручивать все время интересно, если вещь указатель, массив, матрица или безотносительно ...

Но что, если его тип изменится - вы собираетесь просмотреть весь свой код и изменить имена всех переменных. А что если переменная является экземпляром сложного типа: 

ComplicatedDerivativeFinancialInstrument x;

Какой суффикс вы будете использовать?

То, о чем вы спрашиваете, известно как Венгерская нотация - его использование в C ++ почти повсеместно считается плохой идеей.

5 голосов
/ 03 апреля 2009

В C ++ при проектировании / рефакторинге кода довольно часто переходят от указателя (int*) к ссылке (int&). Если бы вы повторили , включив суффикс в имя переменной, указывающий, что это указатель, вам придется заменить его на что-то другое, повсеместно. Это кажется бессмысленной работой, которая только усложняет редактирование кода и превращает его в то, что вы хотите.

Тебе не нужно такого напоминания; например, будет понятно, будет ли переменная указателем или нет.

2 голосов
/ 03 апреля 2009
1 голос
/ 03 апреля 2009
1 голос
/ 03 апреля 2009

Как уже упоминали Нил и Ааронис, вы говорите о форме Венгерской нотации . Поскольку C ++ является языком со строгой типизацией, его обычно считают плохой идеей. Это усложняет чтение кода, потому что мешает множество дополнительных символов.

Оригинальная венгерская запись фактически использовалась для обозначения информации, выходящей за рамки того, что было сказано. Например, скажем, я делаю некоторые графические работы, и у меня есть точки в различных системах координат. Все они имеют тип Point, но некоторые находятся в координатах объекта, некоторые в координатах камеры, а некоторые в мировых координатах. В этом случае имеет смысл назвать их соответствующие переменные как-то вроде oPt, cPt и wPt.

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

1 голос
/ 03 апреля 2009

Существуют хорошие соглашения об именах, но информация о типе в имени переменной (одна форма называется венгерская запись ) становится все менее популярной. Большинство современных IDE предоставят вам полезную информацию о переменной, просто наведя указатель мыши на переменную, такую ​​как ее тип. Однако, если это важно для вас, вероятно, вы хотите использовать венгерскую нотацию.

0 голосов
/ 03 апреля 2009

Если бы в Facebook была группа «Я ненавижу венгерскую нотацию», я бы присоединился к ней.

Вот некоторый псевдокод, иллюстрирующий мой стандарт. 

namespace utilities
{

class MyGizmo
{
public :
   void doTheThing();
   std::string name_;
private:
   int thingCount_;
};

static const char* ApplicationName = "Gizmotronic Ultra 1.0";

void setGizmoName(MyGizmo& gizmo, const std::string & name)
{
   gizmo.name_ = name;
}

int main()
{
   cout << ApplicationName;
   MyGizmo gizmo;
   gizmo.doTheThing();

   std::string gizmoName = gizmo.name_;

   return 0;
}
0 голосов
/ 03 апреля 2009

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

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

  • Определения класса и метода - сначала буква заглавная с первой буквы составных слов также * с заглавной буквы
  • Экземпляры объектов и аргументы функций - сначала строчная буква с первой буквой составных слов с большой буквы
  • Поля данных класса - завершающее подчеркивание, первый буквенный символ строчная с первой буквой объединенные слова с большой буквы

Боюсь, что он, вероятно, не пройдет 10-минутный тест, но если объяснение займет более 10 минут, это, вероятно, помешает реальной работе. 

class FooProblem {
  int fooData_;
  public:
  FooProblem(int fooData): fooData_(fooData){}
};
...