Что такое хорошее соглашение об именах для vars, методов и т. Д. На C++?

Question

Я родом из мира Objective-C и Cocoa, где есть много соглашений, и многие люди скажут, что это делает ваш код красивым! Теперь программирование на C++ Я не могу найти хороший документ, подобный этому для C++.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

Standard C++, вероятно, не что-то вроде выше, но я надеюсь, что смогу придерживаться какой-либо другой SDK или API-интерфейсов (например, от Microsoft (?), И т.д.) конвенций.

Надеюсь, вы можете предоставить мне некоторые ссылки.

Answer 1

Выполняйте все, что хотите, до минимального, согласованного и doesn't break any rules.

Лично я считаю, что стиль 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 

That. (И как я уже говорил в комментариях, не не принять руководство Стиль Google для вашего кода, если это не что-то, как несущественные, как именования.)

Answer 2

Хотя многие люди будут предлагать более или менее строгие варианты Hungarian notation (scary!), Для предложений по именованию я предлагаю вам взглянуть на Google C++ Coding Guidelines. Это может быть не самые популярные соглашения об именах, но, по крайней мере, это довольно полно. Помимо звуковых соглашений об именах, здесь есть некоторые полезные рекомендации, однако многое из этого нужно сделать с помощью соли (например, запрет на исключение и стремление держаться подальше от современного стиля программирования на C++).

Несмотря на то, что мне лично нравится экстремальный стиль нестандартных конвенций STL и Boost;).

Answer 3

не столь краткие, как ссылка вы предоставили: но в следующей главе 14 - 24 может помочь :) хех

ссылка: http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586/ref=sr_1_1?ie=UTF8&s=books&qid=1284443869&sr=8-1-catcorr

Answer 4

Для решения широкого вопроса руководств по стилю я предлагаю выбрать один и придерживаясь этого.
Google style guide очень подробный/всеобъемлющий, так что это хороший выбор.

Общей конвенции только для именования:

• camelCase для всех имен (кроме констант).
• Начиная с капитала, если это класс.
• Нижний регистр, если нет.
• Константы в ALL_CAPS с разделительными работами подчеркивания.
• Функции могут быть записаны так же, как переменные, camelCase (вы можете сказать, что это функция, потому что после нее требуется ()).
• И переменные-члены с префиксом m и поэтому будут написаны mCamelCase.

Это действительно зависит от вас или людей, с которыми вы работаете/с университетом, в котором вы учитесь.

Для подробного ознакомления с различными руководствами по стилю/обоснованиями позади них, выйдите Прагматический программист Эндрю Хант и Дэвид Томас.

Answer 5

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

вола хуже, чем видеть такой код:

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! 

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

Answer 6

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

Так что я буду иметь 2 советов:

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

Остальное зависит от вас.

Answer 7

Существует множество разных правил/соглашений, которые люди используют при кодировании C++. Например, некоторые люди предпочитают разделять слова, используя капиталы (myVar или MyVar), или используя символы подчеркивания (my_var). Как правило, переменные, использующие символы подчеркивания, имеют все строчные буквы (по моему опыту).
Существует также стиль кодирования, называемый венгерский, который, как я полагаю, используется microsoft. Я лично считаю, что это пустая трата времени, но это может оказаться полезным. Это были имена переменных, которым даны короткие префиксы, такие как i или f, для указания типа переменных. Например: int iVarname, char * strVarname.

Принято, что вы заканчиваете имя struct/class с помощью _t, чтобы отличать его от имени переменной. Например .:

class cat_t { 
    ... 
}; 

cat_t myCat; 

Это также общепринято, чтобы добавить аффикс указать указатели, такие как pVariable или variable_p.

В целом, там действительно нет ни одного стандарта, но многие. Выбор, который вы делаете для обозначения ваших переменных, не имеет значения, если он понятен и, прежде всего, последователен. Согласованность, согласованность, КОНСУЛЬТАТИВНОСТЬ! (попробуйте ввести трижды!)

И если все остальное не удается, перейдите по нему в Google.

Answer 8

Мы следуем принципам, перечисленным на этой странице: C++ Programming Style Guidelines

---

Я также рекомендую вам прочитать The Elements of C++ Style by Misfeldt et al, что вполне отличная книга по этой теме.

Answer 9

Я на самом деле часто использую стиль Java: PascalCase для имен типов, camelCase для функций и переменных, CAPITAL_WORDS для макросов препроцессора. Я предпочитаю это по соглашениям Boost/STL, потому что вам не нужно суффиксные типы с _type. Например.

Size size(); 

вместо

size_type size(); // I don't like suffixes 

Это имеет дополнительное преимущество, что код форматировщик StackOverflow распознает Size как имя типа ;-)

Answer 10

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

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

Как уже упоминалось, будьте очень описательными с указанием имен. также очень специфичны для определения областей (типы классов/пространства данных/пространства имен/анонимные пространства имен). в общем, мне действительно нравится большая часть обычной письменной формы java - это хорошая ссылка и похожа на C++.

, как для конкретного появления/наименования, это небольшой пример похож на то, что я использую (переменные/аргументы 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_ */ 

Answer 11

Для чего это стоит, Bjarne Stroustrup, оригинальный автор C++, имеет свой любимый стиль, описанный здесь: http://www.stroustrup.com/bs_faq2.html