17.4.3.1.2 Global names

Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any use.

— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.

A>может вместе что-нибуьд родим

0. Don't sweat the small stuff. (Or: Know what not to standardize.)

Do use consistent formatting within each source file or even each project, because it's jarring to jump around among several styles in the same piece of code. But don't try to enforce consistent formatting across multiple projects or across a company.

Don't overlegislate naming, but do use a consistent naming convention: There are only two must-dos: a) never use "underhanded names," ones that begin with an underscore or that contain a double underscore; and b) always use ONLY_UPPERCASE_NAMES for macros and never think about writing a macro that is a common word or abbreviation (including common template parameters, such as T and U; writing #define T anything is extremely disruptive). Otherwise, do use consistent and meaningful names and follow a file's or module's convention. (If you can't decide on your own naming convention, try this one: Name classes, functions, and enums LikeThis; name variables likeThis; name private member variables likeThis_; and name macros LIKE_THIS.)

void foo() {
    goo( too( 5 ) ); // Что тут написано? too -- это конструктор too или таки функция от int?
    const to& xxx = too( 6 ); // а тут что написано? Это безопасно, или опасно?

    // Хорошо ещё, что так пока нельзя: 
    // auto yyy = too( 0x09 ); // yyy -- оно типа too или нет? :)
}

class MyClass 
{ // Это я так понимаю, что ты хочешь такое?
public:
    int Size() const { return size; } // А так можно?
};

class MyClass {
public:
   // Тут public интерфейс

protected:
   // Тут protected интерфейс

private:
   // Тут private часть

// Эти методы предназначены только для вызова из кода инициализации/деинициализации приложения!!
public:
   static bool Start();
   static void Stop();
};

template<typename TElement> class MyArray {
public:
    typedef TElement AndWhatIMustWriteHere;
    // ...
    
};

void processString( const char* pText ) {
    std::string sText( pText );
    // тут что-то делаем с sText
}

void processString( myLib1::string sText ) {
    std::string sText( sText ); // Как назвать вторую строку?
    // тут что-то делаем с sText
}

void processString( const char* rawText ) {
    std::string text( rawText );
    // тут что-то делаем с text
}

void processString( const char* cString ) {
    std::string cppString( pText );
    doProcess( cppString );
}

void processString( const char* textPtr ) {
    std::string text( textPtr );
    // тут что-то делаем с text
}

if( ... ) { 
} else {
}

if( ... )
{
}
else
{
}

Вот эти несколько слов: стиль программирования меня не волнует. Я достаточно краток? Если хотя бы
половина времени, израсходованного на правильную расстановку фигурных скобок, тратилась на
обдумывание программы или еще лучше — на общение с пользователями, то вся отрасль работала бы
намного эффективнее. Конечно, единство стиля — вещь хорошая, но я еще не видел книги или
руководства по стилю, которые бы стоили даже часового собрания группы в начале проекта. К тому же
ни одна книга или руководство по стилю не превратят код неаккуратного программиста в нечто
осмысленное. В сущности, стиль часто используется как оправдание недостатка внимания к самой
программе. Наконец, я еще не видел, чтобы в спорах о стиле один программист в чем-то убедил
другого, поэтому любые дискуссии на эту тему считаю бесполезной тратой времени.
(с)Джефри Элджер С++ for Real Programmers

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

void foo() {
E>    goo( too( 5 ) ); // Что тут написано? too -- это конструктор too или таки функция от int?
E>    const to& xxx = too( 6 ); // а тут что написано? Это безопасно, или опасно?

E>    // Хорошо ещё, что так пока нельзя: 
E>    // auto yyy = too( 0x09 ); // yyy -- оно типа too или нет? :)
E>}

private int startupTime
public int StartupTime { get; set; }

private:
  int startupTime_;
public:
  int StartupTime() const; // "get" - не должно совпадать с именем класса!
  // если же совпадает, то как вариант getStartupTime() / setStartupTime()

class KickAss
{
public:
   KickAss() {} // здесь!
   ~KickAss() {}
};

class MyClass 
E>{ // Это я так понимаю, что ты хочешь такое?
E>public:
E>    int Size() const { return size; } // А так можно?
E>};

void processString( const char* pText ) {
E>    std::string sText( pText );
E>    // тут что-то делаем с sText
E>}

void processString( myLib1::string sText ) {
E>    std::string sText( sText ); // Как назвать вторую строку?
E>    // тут что-то делаем с sText
E>}

E>Собственно моё ИМХО тут состоит в том, что гребёнку удобнее читать. Да и идентификаторы на число пробелов короче, но гнушный стиль удобнее набирать, особенно слепым десятипальцевым методом... Так что в зависимости от того чего больше предполагается делать с этим кодом читать или писать, такую нотацию и выбираем ТакЧтоЯСвойВыборСделал

A>если же Job является первичным то например BlowJob

A>private:
A>  int startupTime_;
A>public:
A>  int StartupTime() const; // "get" - не должно совпадать с именем класса!
A>  // если же совпадает, то как вариант getStartupTime() / setStartupTime()
A>

class MyClass 
E>>{ // Это я так понимаю, что ты хочешь такое?
E>>public:
E>>    int Size() const { return size; } // А так можно?
E>>};

 for( int i = 1; i < size; i++ );
    doItOneTime();

template<typename TElement_> class MyArray {
public:
    typedef TElement_ TElement;

    // есть, кстати, ещё и вторая похожая тема
    MyArray( int size_ ) : size( size_ ) {...}
};

void processString( myLib1::string sText ) {
E>>    std::string sText( sText ); // Как назвать вторую строку?
E>>    // тут что-то делаем с sText
E>>}

#pragma hintRefact // тут надо бы переписать то и сё

Job jobMonika;
jobMonika = jobKlinton; // Пусть Моника почувствует себя президентом. Сразу видно что мы присваиваем переменной переменную того же типа.

E>Вот, например, какой "венгерский" префикс ты используешь для переменной типа std::vector< std::pair<int, std::string> >::itrrator?

E>Короче пользы мало, да ещё и для большинства переменных и не понятно что писать

spMyPtr = NULL;

class MyClass 
E>>>{ // Это я так понимаю, что ты хочешь такое?
E>>>public:
E>>>    int Size() const { return size; } // А так можно?
E>>>};

 for( int i = 1; i < size; i++ );
E>    doItOneTime();

char const* name = getSomeName(); // правильно?
char const* utf8Name = sSomeNameInLocalCharset(); // пожалуй, нет
std::wstring name = wsFromUtf8(utf8SomeName()); // OK

CC>Как по мне так camelCase читается гораздо естественнее. На lower_case у меня глаза ломаюццо

IllegalIndirection

L>spMyPtr = NULL;
L>

MyData.Delete();

E>Ну в каком контексте надо знать тип переменной, а не её семантику?

arrFoo = arrBar; // При этом arrFoo может быть вектором, а arrBar - boost::array, или чем-то ещё что работает как массив.

pFoo = pBar;

class SomeClass
{
public:
    typedef std::vector<char> Seq;

    Seq const& getData() const;
    void setData(Seq const &);
    
private:
    Seq data_;
};

SomeClass::Seq tlsResponse = sc.getData();
sc.setData(getMoreData());

class SomeClass
{
public:
    typedef std::vector<char> Seq;

    Seq const& rgchData() const;
    void data(Seq const &);
    
private:
    Seq data_;
};

SomeClass::Seq rgchTlsResponse = sc.rgchData();
sc.data(rgchGetMoreData());