Я родом из мира Objective-C и Cocoa, где есть много соглашений, и многие люди скажут, что он делает ваш код красивым! Теперь программирование на С++ я не могу найти хороший документ, подобный этому для С++.
Стандарт С++, вероятно, не имеет ничего подобного выше, но я надеюсь, что смогу придерживаться некоторых других SDK или API (например, Microsoft (?) и т.д.).
Надеюсь, вы можете предоставить мне некоторые ссылки.
Делайте все, что хотите, пока его минимальная, согласованная и не нарушает никаких правил.
Лично я считаю, что стиль Boost проще всего; он соответствует стандартной библиотеке (дает единый взгляд на код) и прост. Я лично привязываю к префиксам m и p к членам и параметрам, соответственно, предоставляя:
#ifndef NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP
#define NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP
#include <boost/headers/go/first>
#include <boost/in_alphabetical/order>
#include <then_standard_headers>
#include <in_alphabetical_order>
#include "then/any/detail/headers"
#include "in/alphabetical/order"
#include "then/any/remaining/headers/in"
// (you'll never guess)
#include "alphabetical/order/duh"
#define NAMESPACE_NAMES_THEN_MACRO_NAME(pMacroNames) ARE_ALL_CAPS
namespace lowercase_identifers
{
class separated_by_underscores
{
public:
void because_underscores_are() const
{
volatile int mostLikeSpaces = 0; // but local names are condensed
while (!mostLikeSpaces)
single_statements(); // don't need braces
for (size_t i = 0; i < 100; ++i)
{
but_multiple(i);
statements_do();
}
}
const complex_type& value() const
{
return mValue; // no conflict with value here
}
void value(const complex_type& pValue)
{
mValue = pValue ; // or here
}
protected:
// the more public it is, the more important it is,
// so order: public on top, then protected then private
template <typename Template, typename Parameters>
void are_upper_camel_case()
{
// gman was here
}
private:
complex_type mValue;
};
}
#endif
Это. (И, как я уже сказал в комментариях, не принимайте руководство по стилю Google для своего кода, если только оно не является чем-то несущественным, как соглашение об именах.)
Есть, вероятно, столько же соглашений об именах, сколько есть людей, дебаты бесконечны (и стерильны) относительно того, какой стиль фигурной скобки использовать и т.д.
Итак, у меня будет 2 совета:
Остальное зависит от вас.
Я на самом деле часто использую стиль Java: PascalCase для имен типов, camelCase для функций и переменных, CAPITAL_WORDS для макросов препроцессора. Я предпочитаю это по соглашениям Boost/STL, потому что вам не нужно суффицировать типы с помощью _type. Например.
Size size();
вместо
size_type size(); // I don't like suffixes
Это дает дополнительное преимущество в том, что форматировщик кода StackOverflow распознает Size как имя типа; -)
Мы следуем рекомендациям, перечисленным на этой странице: Руководства по стилю программирования на С++
Я также рекомендую вам читать The Elements of С++ Style by Misfeldt и др., что является отличной книгой по этой теме.
Для чего это стоит, Bjarne Stroustrup, автор оригинала С++, имеет свой любимый стиль, описанный здесь: http://www.stroustrup.com/bs_faq2.html
Хотя многие люди будут предлагать более или менее строгие венгерские нотации (страшно!), для предложений по именованию я предлагаю вам взглянуть на Правила кодирования Google С++. Это может быть не самые популярные соглашения об именах, но, по крайней мере, это довольно полно. Помимо звуковых соглашений об именах, там есть некоторые полезные рекомендации, однако многое из этого нужно брать с помощью соли (например, запрет на исключение и стремление держаться подальше от современного стиля программирования на С++).
Несмотря на то, что мне лично нравится экстремальный стиль низкотехнологичных конвенций STL и Boost;).
Для решения более широкой проблемы руководств по стилю я предлагаю выбрать один и придерживаться его.
руководство по стилю Google очень детализировано/полно, поэтому это хороший выбор.
Общим соглашением для наименования является:
camelCase для всех имен (кроме констант).ALL_CAPS с разделительными работами подчеркивания.camelCase (вы можете указать ему функцию, потому что после нее требуется ()).m и, следовательно, будут записаны mCamelCase.Это действительно зависит от вас или людей, с которыми вы работаете/с университетом, в котором вы учитесь.
Подробную информацию о различных руководствах/обоснованиях стилей позади, посмотрите прагматического программиста Эндрю Ханта и Дэвида Томаса.
важны последовательность и читаемость (самодокументирующий код). некоторые подсказки (например, случай) могут и должны использоваться, чтобы избежать столкновений, и указать, требуется ли экземпляр.
Одна из лучших практик, с которой я столкнулась, заключалась в использовании форматировщиков кода (астилы и uncrustify - 2 примера). форматирование кода может уничтожить форматирование вашего кода - настроить форматтер и позволить ему выполнять свою работу. серьезно, забыть о ручном форматировании и вникать в практику их использования. они сэкономят массу времени.
как уже упоминалось, очень описательно с именованием. также очень специфичны для определения областей (типы классов/пространства данных/пространства имен/анонимные пространства имен). в общем, мне очень нравится большая часть общей текстовой формы java - это хорошая ссылка и похожа на С++.
как для конкретного вида/наименования, это небольшой пример, аналогичный тому, что я использую (переменные/аргументы lowerCamel, и это только демонстрирует часть языковых возможностей):
/** MYC_BEGIN_FILE_ID::FD_Directory_nanotimer_FN_nanotimer_hpp_::MYC_BEGIN_FILE_DIR::Directory/nanotimer::MYC_BEGIN_FILE_FILE::nanotimer.hpp::Copyright... */
#ifndef FD_Directory_nanotimer_FN_nanotimer_hpp_
#define FD_Directory_nanotimer_FN_nanotimer_hpp_
/* typical commentary omitted -- comments detail notations/conventions. also, no defines/macros other than header guards */
namespace NamespaceName {
/* types prefixed with 't_' */
class t_nanotimer : public t_base_timer {
/* private types */
class t_thing {
/*...*/
};
public:
/* public types */
typedef uint64_t t_nanosecond;
/* factory initializers -- UpperCamel */
t_nanotimer* WithFloat(const float& arg);
/* public/protected class interface -- UpperCamel */
static float Uptime();
protected:
/* static class data -- UpperCamel -- accessors, if needed, use Get/Set prefix */
static const t_spoke Spoke;
public:
/* enums in interface are labeled as static class data */
enum { Granularity = 4 };
public:
/* construction/destruction -- always use proper initialization list */
explicit t_nanotimer(t_init);
explicit t_nanotimer(const float& arg);
virtual ~t_nanotimer();
/*
public and protected instance methods -- lowercaseCamel()
- booleans prefer is/has
- accessors use the form: getVariable() setVariable().
const-correctness is important
*/
const void* address() const;
virtual uint64_t hashCode() const;
protected:
/* interfaces/implementation of base pure virtuals (assume this was pure virtual in t_base_timer) */
virtual bool hasExpired() const;
private:
/* private methods and private static data */
void invalidate();
private:
/*
instance variables
- i tend to use underscore suffix, but d_ (for example) is another good alternative
- note redundancy in visibility
*/
t_thing ivar_;
private:
/* prohibited stuff */
explicit t_nanotimer();
explicit t_nanotimer(const int&);
};
} /* << NamespaceName */
/* i often add a multiple include else block here, preferring package-style inclusions */
#endif /* MYC_END_FILE::FD_Directory_nanotimer_FN_nanotimer_hpp_ */
Это действительно неважно. Просто убедитесь, что вы назовете свои переменные и функции описательно. Также будьте последовательны.
Теперь хуже, чем просмотр кода следующим образом:
int anInt; // Great name for a variable there ...
int myVar = Func( anInt ); // And on this line a great name for a function and myVar
// lacks the consistency already, poorly, laid out!
Изменить: Как отметил мой комментатор, последовательность должна поддерживаться во всей команде. Как таковой не имеет значения, какой метод вы выбрали, если эта последовательность сохраняется. Однако нет правильного или неправильного метода. У каждой команды, с которой я работал, были разные идеи, и я адаптировался к этим.
Существует множество разных правил/соглашений, которые люди используют при кодировании С++. Например, некоторые люди предпочитают разделять слова, используя капиталы (myVar или MyVar), или используя символы подчеркивания (my_var). Как правило, переменные, использующие символы подчеркивания, находятся во всех строчных строках (по моему опыту).
Существует также стиль кодирования под названием "венгерский", который, как мне кажется, используется Microsoft. Я лично считаю, что это пустая трата времени, но это может оказаться полезным. Это были имена переменных, которым даны короткие префиксы, такие как я или f, для указания типа переменных. Например: int iVarname, char * strVarname.
Принято, что вы заканчиваете имя struct/class с помощью _t, чтобы отличать его от имени переменной. Например:.
class cat_t {
...
};
cat_t myCat;
Также принято добавлять аффикс для указания указателей, таких как pVariable или variable_p.
В целом, действительно нет ни одного стандарта, кроме многих. Выбор, который вы делаете для обозначения ваших переменных, не имеет значения, если он понятен и, прежде всего, последователен. Согласованность, согласованность, КОНСУЛЬТАТИВНОСТЬ! (попробуйте ввести трижды!)
И если все остальное не удается, выполните его.
не так лаконичен, как ссылка, которую вы указали: но следующая глава 14-24 может помочь:) Хехе