Re: А в чём смысл?
От: Erop Россия  
Дата: 18.09.07 20:03
Оценка: 5 (1) +5
Здравствуйте, Awaken, Вы писали:

A>ни разу еще не видел хорошего стандарта по кодированию C++

A>либо используется старый майкрософтовский стиль (hungarian notation, классы с буквой C впереди),
Вообще-то фирма MS многого добилась в групповой разработке ПО. ИМХО их опыт отвергать стоит только понимая почему ты его отвергаешь

A>либо гнушно-юниксовый стиль (все с прописной буквы и подчеркивания),

AFAIK и гиусовцы многого добились на анологичном поприще...

A>либо его вообще нет

A>вот что мне видится более-менее рациональным:
Главное не описано, а зачем нужно то, или иное ограничение?

A>-не используем C как префикс имени класса (долой наследие MFC!)

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

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


A>-не используем префиксы библиотек в имени класса, используем неймспейсы вместо

A>-используем вложенные неймспейсы для указания на иерархию библиотек,
A>впереди название продукта, затем подсистемы и библиотеки
A>MMS::core::utility::SomeClass вместо CMMSSomeClass
А зачем? Ещё MMS::SomwClass я понимаю зачем, но вот зачем там ещё и core::utility:: ?
A>-не используем венгерскую нотацию, за небольшими исключениями (см.ниже)
ИМХО обсуждаемо
A>-идентификаторы классов — с большой буквы, паскаль-стиль: SomeClass
A>-переменные на стеке — прописными буквами (гнушный стиль): local_variable_x
а что делать с однословными классами и переменными?

A>-переменные члены класса — джавовский стиль с подчеркиванием: _memberVariable

A>(насчет последнего — не уверен, как красивее. раньше было: m_memberVar )
А в чём во всём этом смысл?
A>скобки — попарно друг под другом:
A>{
A>}
Даже в определении класса?
А можно ли написать так, например:
class MyClass 
{ // Это я так понимаю, что ты хочешь такое?
public:
    int Size() const { return size; } // А так можно?
};

A>-области видимости внутри класса идут в порядке: public, protected, private
А если это неудобно почему-то?
А если есть такая секция public:
class MyClass {
public:
   // Тут public интерфейс

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

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

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

A>-аргументы шаблона называем с префиксом T: TArg, TFun
А typedef'ы?
Например такие:
template<typename TElement> class MyArray {
public:
    typedef TElement AndWhatIMustWriteHere;
    // ...
    
};


Могу поделиться своими соображениями по приведённым и неприведённым пунктам.

1) Венгерская нотация, ИМХО устарела почти везде. Дело в том, что она была очень нужна в C, так как там не было таки контроля типов, кроме глаз программиста. Теперь, если писать в С++ стиле, то всё понимает сам компилятор.
То есть мне кажется, что лучше давать понятные имена переменным, а не приписывать к ним длинные предлинные префиксы. Ну типа вместо sText писать просто Text да и всё, а вместо nItems писать ItemsCount
2) Отдельным применением венгерской нотации является использование префикса типа для различения разных представлений одних и тех же данных. Например как-то так:
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
}

3) Гребёнка от M$ vs гнушный стиль.
Собственно моё ИМХО тут состоит в том, что гребёнку удобнее читать. Да и идентификаторы на число пробелов короче, но гнушный стиль удобнее набирать, особенно слепым десятипальцевым методом... Так что в зависимости от того чего больше предполагается делать с этим кодом читать или писать, такую нотацию и выбираем ТакЧтоЯСвойВыборСделал
4) Пефиксы имён классов
Собственно префиксы имён классов нужны для того, чтобы подсказать программисту, который читает код что обозначает запись. Преобразование типа или вызов функции или создание временного объекта. Так как у временных объектов иногда другие бывают повадки, чем у функций.
5) Отличие локальных переменных от функций и глобальных переменных и членов
ИМХО лучше всё называть так, чтобы было понятно из названия непосредственно, но это не всегда удобно и даже возможно. Я бы как-то выделял члены (скорее всего при помощи постфикса _m), для которых крайне критично понимать, что они члены внутри реализации методов. ИМХО обычно это не нужно, так как можно дать члену класса такое название, что понятно что это такое.
С другой стороны, когда пишешь код метода и хочешь подчеркнуть, что это таки член, ты в нестатических методах можешь написать this->member...
Про отличение классов от переменных и функций я уже писал. Остался ещё один аспект. Отличение глобальных имён о локальных.
Ну типа там локальных переменных от глобальных, параметров метода от членов класса и т. д.
Я придерживаюсь такого подхода, что локальные сущности называю с маленькой буквы, а нелокальные с большой. Но и даже это, ИМХО, не особо-то и нужно...
6) Размещение скобок.
ИМХО намного важнее, чтобы скобки распалагались симметрично
Ну типа или так:
if( ... ) { 
} else {
}
или так:
if( ... )
{
}
else
{
}
но при этом стоит таки оставить возможность писать методы в одну строку
7) Ещё, ИМХО, очень ценным является принципы "одно действие -- одна строка" и "слишком сложное выражение надо явно разбить на части"

Ну и ещё немного о принципах.
Собственно стандарт должне быть направлен на то, чтобы облегчить чтение и поддержку чужого кода, ИМХО, поэтому крайне нехорошо использовать правила, которые мешают что-то понимать при чтении программы. Особенно если для понимания надо куда-то лезть и смотреть какие-то определения. Избегание такого косяка намного важнее каких-то формальных огранияений, ИМХО всё разумеется
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: правильный современный стиль кодирования на C++?
От: ShaggyOwl Россия http://www.rsdn.org
Дата: 19.09.07 08:17
Оценка: 26 (4)
Здравствуйте, Awaken, Вы писали:

A>ни разу еще не видел хорошего стандарта по кодированию C++


Сразу бы сказал, что хочешь услышать, а то пост в полувакуум был
http://www.rsdn.ru/Forum/?mid=1999144
Автор: FreshMeat
Дата: 13.07.06
(посмотри док от команды буста)
Специально для лентяев Coding Standard Generator
В гугле первой ссылкой падает http://www.chris-lott.org/resources/cstyle/, подробнее не смотрел.

По твоему стандарту кодирования только одна претензия — пиши к каждому пункту
1. обоснования/достоинства (rationale)
2. возможные претензии/недостатки
Тогда обсуждать документ с коллегами (или объяснять эти правила новичку) будет существенно проще.

Касаемо коментариев по пунктам — Erop раскрыл тему.
Хорошо там, где мы есть! :)
Re[2]: А в чём смысл?
От: Awaken Украина  
Дата: 19.09.07 07:09
Оценка: 12 (2) +1
A>>-не используем C как префикс имени класса (долой наследие MFC!)
E>А чем это плохо?
void foo() {
E>    goo( too( 5 ) ); // Что тут написано? too -- это конструктор too или таки функция от int?
E>    const to& xxx = too( 6 ); // а тут что написано? Это безопасно, или опасно?

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


тем что используются бессмысленные имена.
идентификатор класса и методов должны нести какой-то смысл.
часто используется такое соглашение:
Имя класса — существительное (англ.), дополнительная характеристика класса — прилагательное или др.описательная часть речи (впереди имени)
т.е. JobMonitor а не MonitorJob (если речь о "мониторе" контролирующем какие-то задания)
если же Job является первичным то например BlowJob


A>>MMS::core::utility::SomeClass вместо CMMSSomeClass

E>А зачем? Ещё MMS::SomwClass я понимаю зачем, но вот зачем там ещё и core::utility:: ?

это необязательно, но в больших проектах состоящих из многих исходников, защищает от коллизий имен.
например есть MMS::Presentation::DataAdapter и MMS::DataAccess::DataAdapter
(можно конечно и так: MMS_Presentation и MMS_DataAccess)

E>а что делать с однословными классами и переменными?

это как? по моему такого быть не должно. если в классе есть переменная член, у нее кейс будет другой.
в С# нотация с разными кейсами первой буквы используется чтоб отличить внешний метод (property),
от внутренней переменной имеющей тот же смысл, например
private int startupTime
public int StartupTime { get; set; }

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


A>>-переменные члены класса — джавовский стиль с подчеркиванием: _memberVariable

A>>(насчет последнего — не уверен, как красивее. раньше было: m_memberVar )
E>А в чём во всём этом смысл?
A>>скобки — попарно друг под другом:
A>>{
A>>}
E>Даже в определении класса?
допустимое исключение — тела "пустых" методов, например:
class KickAss
{
public:
   KickAss() {} // здесь!
   ~KickAss() {}
};


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


согласен, это частный случай предыдущего

A>>-области видимости внутри класса идут в порядке: public, protected, private

E>А если это неудобно почему-то?

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

A>>-аргументы шаблона называем с префиксом T: TArg, TFun

E>А typedef'ы?

typedefы обычно должны нести смысл того типа который они переопределяют.
т.е. то же соглашение что для имен классов.

E>То есть мне кажется, что лучше давать понятные имена переменным, а не приписывать к ним длинные предлинные префиксы. Ну типа вместо sText писать >просто Text да и всё, а вместо nItems писать ItemsCount


осмысленные имена — ключ к хорошо читаемому коду.
например inputToken лучше чем малопонятный strString, даже если это временная переменная.
из названия следует что токен — это элемент какой-то входной строки, скармливаемый парсеру за раз

E>2) Отдельным применением венгерской нотации является использование префикса типа для различения разных представлений одних и тех же данных. Например как-то так:
void processString( const char* pText ) {
E>    std::string sText( pText );
E>    // тут что-то делаем с sText
E>}

E>ИМХО в таком случае можно применять и венгерскую нотацию, если у тебя есть какой-то простой способ порождать на все типы префиксы, потому что иначе ты упрёшься в такую попу:
void processString( myLib1::string sText ) {
E>    std::string sText( sText ); // Как назвать вторую строку?
E>    // тут что-то делаем с sText
E>}


зачем это делать? это перегрузка с разными аргументами, но смысл аргументов одинаков, просто представлен разными типами.
имхо здесь это совершенно лишнее

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

+1

E>С другой стороны, когда пишешь код метода и хочешь подчеркнуть, что это таки член, ты в нестатических методах можешь написать this->member...

+1
иногда специально так пишу, хотя это длиннее.

E>Про отличение классов от переменных и функций я уже писал. Остался ещё один аспект. Отличение глобальных имён о локальных.

E>Ну типа там локальных переменных от глобальных, параметров метода от членов класса и т. д.

глобальные переменные мы называли с префиксом g_
g_Logger;
но можно их и не использовать напрямую, а использовать статические методы синглтонов,
т.е. Logger::Instance() . тогда проблема именования отпадет

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

E>7) Ещё, ИМХО, очень ценным является принципы "одно действие -- одна строка" и "слишком сложное выражение надо явно разбить на части"

+1

еще про именования локальных переменных:
общеупотребимые "бессмысленные" имена допустимы для кратковременно живущих локальных переменных
i,j — счетчики цикла
p — то же для указателей , например в конструкциях типа while (*p++ )
it — временный итератор , например в циклах типа for ( it = v.begin(); it != v.end(); ++it)
ret, retVal — временная копия возвращаемого значения функции (если ее нельзя вычислить в точке возврата)


спец.комментарии (нотация позаимствована с моей предыдущей работы).
состоят из ключевого слова и краткого описания сути проблемы.
спец.комментарии предназначены для привлечения внимания того кто делает code review,
или для облегчения поиска подобных мест скриптами и анализаторами кода
// BUG:
// ISSUE:
-известные проблемы, которые не могут быть пофиксены сейчас. оставлены до след.релиза
// TRICKY:
-нетривиальный, сложный кусок кода или алгоритм. предупредждение "не лезь если не знаешь как работает"
// UGLY:
-"затычка", временное, некрасивое или неоптимальное решение. указание что кусок кода должен быть переписан по возможности
// REFACTOR:
-похоже на предыдущее но менее строгое. код который возможно подвергнется рефакторингу
// TODO:
-указывает на недописанный кусок кода.
Re[3]: правильный современный стиль кодирования на C++?
От: sc Россия  
Дата: 18.09.07 19:20
Оценка: 2 (2) +1
Здравствуйте, Awaken, Вы писали:

S>>и всё это без аргументов и обоснований,

S>>ещё скажи goto и макросы не используем.

A>обоснования нужны для корпоративного документа, я же тут не документ пишу

A>это обмен опытом по написанию стандартов кодирования
A>может вместе что-нибуьд родим

Известные чуваки, Саттер и Александреску в своих 101 правилах пишут:

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.)

Re: правильный современный стиль кодирования на C++?
От: AndrewJD США  
Дата: 18.09.07 16:17
Оценка: 4 (2)
Здравствуйте, Awaken, Вы писали:

A>ни разу еще не видел хорошего стандарта по кодированию C++


Как вариант
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re: правильный современный стиль кодирования на C++?
От: Left2 Украина  
Дата: 18.09.07 16:11
Оценка: +2
Тут как бы возможны следующие случаи:

1. У команды разработчиков уже есть coding guidelines и они уже давно используются в проекте — ИМХО, нет смысла заменять их новыми, разве что по общему согласию избавиться от наиболее устаревших и раздражающих пунктов.
2. Coding guidelines нет вообще (команда разработчиков только что создана, к примеру). Тогда — следующие подпункты:
2.1 Поддержка (вариант — развитие) старого С++ проекта — как правило, коней на переправе не меняют и используют тот стиль coding guidelines который был в этом проекте изначально.
2.2 Написание нового проекта — как правило, проект не пишется с нуля а базируется на каких-то библиотеках. В этом случае имеет смысл взять coding guidelines из той библиотеки которая наиболее часто используется в проекте (к примеру — если ты пишешь COM на ATL, то и guidelines лучше подогнать под него).
2.3 Ситуация не подходит ни под один из пунктов — в этом случае надо писать свои coding guidelines. Лично у меня ни один из пунктов которые ты перечислил принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но переусердствовать в ней явно не стоит. К примеру, в 99% случаев переменную лучше назвать strWindowCaption вместо lpctstrWindowCaption или iLineCount вместо uiLineCount.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[2]: правильный современный стиль кодирования на C++?
От: moorgeist  
Дата: 19.09.07 04:35
Оценка: +2
Здравствуйте, dip_2000, Вы писали:

_>[q]

_>Вот эти несколько слов: стиль программирования меня не волнует. Я достаточно краток? Если хотя бы
_>половина времени, израсходованного на правильную расстановку фигурных скобок, тратилась на
_>обдумывание программы или еще лучше — на общение с пользователями, то вся отрасль работала бы
_>намного эффективнее.

+1, добавить нечего
Хороший стиль кодирования должен быть основан не на соглашениях о способе расстановки скобочек, а на соглашениях о используемых идиомах языка.
Re[3]: правильный современный стиль кодирования на C++?
От: green.nsk  
Дата: 19.09.07 05:06
Оценка: +2
OE>не превратят, факт. Только вот для того чтобы понять насколько этот код осмысленный и в каких местах, времени, за экономию которого так страдает Элджер, понадобится раз в 10 меньше.

Просто надо находить компромисс. Я считаю, что я достаточно аккуратно оформляю код. Ну то есть соблюдаю отступы (точнее, это делает assist), не пишу сильно длинные строки, не делаю несколько действий в одной строке, стараюсь не писать сильно длинных методов и выбираю осмысленные имена. Однако, подобные стандарты придираются к каждой запятой, и мало кто оговаривает степень их строгости — обычно пишут "следует применять, следует оформлять". В тех станадртах оформления, которые видел я, очень редко встречается слово "рекомендуется".

По-моему, вменяемый программист обычно нормально оформляет код в любом стиле. По своему опыту скажу, что читать и даже писать код в другом стиле привыкаешь за полдня-день (это включает camel-gnu оформление, использование-неиспользование венгерской нотации и т.п.), если не требуется соблюдать все правила фанатично — то есть если меня не будут бить по башке, кодга я вместо uiCount напишу iCount, как тут уже приводили пример.

В общем, хотел сказать, что я не понимаю педантичного следования правилам. Минимум форматирования обеспечит IDE, остальное — придёт с опытом. А доскональное оформление кода по coding guidelines нерационально (ну скажите, какая разница, напишу я f(x, y) или f( x, y )? лично у меня ни один из вариантов отторжения не вызывает). Выбрать и настроить IDE один раз — может быть и стоит, но вручную следить за тем, все ли пробелы я написал, а тем более придираться к другим — меня не тянет.
Re[4]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 06:32
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

E>Ну тогда без ложной скромности: http://eao197.narod.ru/desc/lower_case.htm

E>Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.
Как по мне так camelCase читается гораздо естественнее. На lower_case у меня глаза ломаюццо
Что впрочем лишний раз подтверждает что на вкус и цвет...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: правильный современный стиль кодирования на C++?
От: Left2 Украина  
Дата: 19.09.07 08:04
Оценка: -2
CC>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist
Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения. Ну и опять же, не всегда код читают из IDE. Assist это безусловно отличная тулза, но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[5]: о фломастерах...
От: Erop Россия  
Дата: 19.09.07 06:51
Оценка: 1 (1)
Здравствуйте, CreatorCray, Вы писали:

E>>Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.

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

ИМХО это подтверждает только то, что вы поразному IDE настраиваете. Размер и тип шрифта, цвета и т. д.
Но, тем не менее, если говорить о читабельности, то большинство ников на rsdn таки в camelCase, ИМХО...
Наверное это просто к естественному языку юлиже. ЛогоВАЗ там всякие и CuneiForm
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: правильный современный стиль кодирования на C++?
От: Аноним  
Дата: 18.09.07 15:32
Оценка: +1
Тебе это надо не тут обсуждать, а с теми, кто по нему жить будет.
Нету "правильного современного стиля кодирования".
Re: правильный современный стиль кодирования на C++?
От: Sharp Eye Россия  
Дата: 18.09.07 17:06
Оценка: +1
Здравствуйте, Awaken, Вы писали:

...
A>-переменные члены класса — джавовский стиль с подчеркиванием: _memberVariable
Начинать имя с подчеркивания — это не хорошо :


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.


Re[6]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 07:32
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, CreatorCray, Вы писали:


E>>>Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а

CC>>За что ж тебя так жОстко то?
E>Ну код подчинённых, код, присланный на аттестацию, код в соседней подсистеме обычно неудобно открывать в IDE, вполне достаточно и NotePad'а...
Я по старой привычке обычно фаром F3 или F4. Тока вот если сурс больше чем 1 файл и есть зависимости туда-сюда то проще его в визжалку загрузить и там побегать. У нас щас принудительно перешли на 2005-ю, но я себе оставил 2003-ю, она куда шустрее бегает, вот ей и открываю все стороннее. Так заодно и основная среда (2005) не засоряется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 08:54
Оценка: +1
Здравствуйте, Left2, Вы писали:

CC>>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist

L>Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения.
Представь себе, еложу. Я еще и мышыным колесом скролю.
Информация о типе лично мне нужна только тогда, если из кода нифига не понятна его логика, или она очень сильно завязана на типах.

L>но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.

Мое мнение — префиксы в большинстве своем это рудимент, только засоряющий код. Чтение от их наличия зачастую ИМХО только ухудшается. А какая свистопляска начинается при смене типа переменной — этож везде где она используется надо имена поменять. А нормальные тулы для рефакторинга для С++ не так уж давно появились.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: правильный современный стиль кодирования на C++?
От: Awaken Украина  
Дата: 19.09.07 11:10
Оценка: +1
CC>>Информация о типе лично мне нужна только тогда, если из кода нифига не понятна его логика, или она очень сильно завязана на типах.
L>Логика довольно часто завязана на типы. Не завязана на типы она, пожалуй, в основном только в шаблонном коде. А шаблонного кода обычно в проекте мало или очень мало по сравнению с нешаблонным.

L>>>но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают >читабельность кода.


проблема венгерки в том что она не консистентна.
она разрабатывалась для Си, где есть только простые типы.

если следовать этим же правилам в C++ , получается что нужно перед каждым именем переменной-экземпляра класса,
писать имя его типа

Dick clsDickClintonDick;
Job clsJobMonikaJob;

бредово и громоздко не правда ли?
так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна
Re[9]: правильный современный стиль кодирования на C++?
От: Erop Россия  
Дата: 19.09.07 11:36
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

E>>Ну фар или NotePad не так уж и разнятся.

CC>Раскраской синтаксиса как минимум.
ИМХО, вопрос привычки

E>>А вообще хинт в том, что даже если у тебя есть пять файлов из проекта, где их 1000, то без проекта IDE тебе не поможет

CC>Зачастую все же помогает.
Ну да, но и просто поиск рулит, а ещё больше рулит хороший код
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: А в чём смысл?
От: Roman Odaisky Украина  
Дата: 19.09.07 12:38
Оценка: +1
Здравствуйте, Erop, Вы писали:

A>>т.е. JobMonitor а не MonitorJob (если речь о "мониторе" контролирующем какие-то задания)

A>>если же Job является первичным то например BlowJob :)
E>Это всё хорошо, и в целом просто сводится к рекомендации "изучите английский" :)
E>Но в этом причудливом языке часто нельзя сказать что за часть речи мы видим.
E>Вот, например, LinkMonitor -- это функция или класс :)

LinkMonitor — наблюдатель за ссылками
linkMonitor — подключить монитор


E>Да и вообще мне всё-таки нраыится правило "потроха с маленькой, морда с большой" :)

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

A>>согласен, это частный случай предыдущего

Use the force. Если от нарушения правила становится читабельнее, нарушай. Если приходится часто нарушать, то вряд ли это хорошее правило.

E>Я бы всё-таки советовал тебе не заморачиваться на точном следовании расстановки скобок именно так. Предложи все популярные вменяемые паттерны, правда я бы запретил if, for, while и do while без скобок использовать. Чтобы такие косяки не сбивали:
 for( int i = 1; i < size; i++ );
E>    doItOneTime();


+1. Кроме else if, и кроме if(expr); else в макросах.

E>>>ИМХО в таком случае можно применять и венгерскую нотацию, если у тебя есть какой-то простой способ порождать на все типы префиксы, потому что иначе ты упрёшься


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



E>Про спец. комменты тоже правильно. Только ещё классно эти все комменты где-то регить.


MSVS вроде понимает //TODO, //FIXME и т. п. — отображает их в том же окошке, что и ошибки (предупреждения) компиляции.
До последнего не верил в пирамиду Лебедева.
Re[10]: всё за читабельность...
От: Erop Россия  
Дата: 19.09.07 16:02
Оценка: +1
Здравствуйте, Left2, Вы писали:

L>bpfNextAttempt и bpfNewAttempt — вполне себе неплохо отличаются. Префикс должен быть маленкими буквами и не больше 3-4 букв.


Очень хорошо, а для классов BestStepFinder и BestStrokeFinder?
Мало того, как не запутаться, вот как по префиксу ssc восстановить AsianLangs::SimpleScriptCharater, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: всё за читабельность...
От: Roman Odaisky Украина  
Дата: 19.09.07 16:42
Оценка: +1
Здравствуйте, Erop, Вы писали:

L>>bpfNextAttempt и bpfNewAttempt — вполне себе неплохо отличаются. Префикс должен быть маленкими буквами и не больше 3-4 букв.


E>Очень хорошо, а для классов BestStepFinder и BestStrokeFinder? :)

E>Мало того, как не запутаться, вот как по префиксу ssc восстановить AsianLangs::SimpleScriptCharater, например? :)

Это уже извращение. И bpf — извращение. Чтобы понять, что xxxNextAttempt — экземпляр класса BestPathFinder, можно подвести к нему мышку (в IDE). Нужно называть nextAttempt, или finderNextAttempt, если тот факт, что это класс, сильно меняет дело. Суть венгерской нотации не в lpsz, и даже не в irgch, а всего лишь в том, что суть переменной отправляется в начало идентификатора. Любой уважающий себя разработчик упомянет в имени переменной типа char const * тот факт, что она UTF-8, «венгр» просто отправит этот префикс в начало. Это strlen(nameInUtf8) vs. cOfUtf8(utf8Name).

С венгерской нотацией, кстати, можно избавиться от префиксов get/set. Например:
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());
До последнего не верил в пирамиду Лебедева.
правильный современный стиль кодирования на C++?
От: Awaken Украина  
Дата: 18.09.07 14:52
Оценка:
ни разу еще не видел хорошего стандарта по кодированию C++
либо используется старый майкрософтовский стиль (hungarian notation, классы с буквой C впереди),
либо гнушно-юниксовый стиль (все с прописной буквы и подчеркивания),
либо его вообще нет
вот что мне видится более-менее рациональным:
-не используем C как префикс имени класса (долой наследие MFC!)
-не используем префиксы библиотек в имени класса, используем неймспейсы вместо
-используем вложенные неймспейсы для указания на иерархию библиотек,
впереди название продукта, затем подсистемы и библиотеки
MMS::core::utility::SomeClass вместо CMMSSomeClass
-не используем венгерскую нотацию, за небольшими исключениями (см.ниже)
-идентификаторы классов — с большой буквы, паскаль-стиль: SomeClass
-переменные на стеке — прописными буквами (гнушный стиль): local_variable_x
-переменные члены класса — джавовский стиль с подчеркиванием: _memberVariable
(насчет последнего — не уверен, как красивее. раньше было: m_memberVar )
скобки — попарно друг под другом:
{
}
-области видимости внутри класса идут в порядке: public, protected, private
-аргументы шаблона называем с префиксом T: TArg, TFun
Re: правильный современный стиль кодирования на C++?
От: Sni4ok  
Дата: 18.09.07 17:09
Оценка:
и всё это без аргументов и обоснований,
ещё скажи goto и макросы не используем.
короче незачёт.
Re[2]: правильный современный стиль кодирования на C++?
От: Awaken Украина  
Дата: 18.09.07 17:41
Оценка:
L> 2.3 Ситуация не подходит ни под один из пунктов — в этом случае надо писать свои coding guidelines. Лично у меня ни один из пунктов которые ты >перечислил принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но

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

копировать стиль из библиотек имхо не есть гуд, если ты не расширяешь саму эту библиотеку.
таким образом мы явно разделяем что вот эти классы — "наши", а иные — из библиотеки
(ну и неймспейсы с названием проекта для того и придумываются)
Re[2]: правильный современный стиль кодирования на C++?
От: Awaken Украина  
Дата: 18.09.07 17:44
Оценка:
S>и всё это без аргументов и обоснований,
S>ещё скажи goto и макросы не используем.

обоснования нужны для корпоративного документа, я же тут не документ пишу
это обмен опытом по написанию стандартов кодирования
может вместе что-нибуьд родим
Re[3]: правильный современный стиль кодирования на C++?
От: Sni4ok  
Дата: 18.09.07 18:58
Оценка:
Здравствуйте, Awaken, Вы писали:

A>обоснования нужны для корпоративного документа, я же тут не документ пишу

A>это обмен опытом по написанию стандартов кодирования
A>может вместе что-нибуьд родим

помоему требования писать код удовлетворяющий хотябы базовой гарантии было бы достаточно,
даже к такой малости не все могут привыкнуть.
Re[3]: правильный современный стиль кодирования на C++?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.09.07 19:47
Оценка:
Здравствуйте, Awaken, Вы писали:

L>> 2.3 Ситуация не подходит ни под один из пунктов — в этом случае надо писать свои coding guidelines. Лично у меня ни один из пунктов которые ты >перечислил принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но


A>меня в боьлшей степени интересуют мнения людей которые сами эти стандарты придумывают.

A>ибо иногда приходится этим заниматься

Ну тогда без ложной скромности: http://eao197.narod.ru/desc/lower_case.htm
Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: правильный современный стиль кодирования на C++?
От: moorgeist  
Дата: 19.09.07 03:39
Оценка:
Здравствуйте, Awaken, Вы писали:

A>ни разу еще не видел хорошего стандарта по кодированию C++

ИМХО, у каждого программиста рано или поздно возникает желание создать самый лучший в его понимании стандарт кодирования.
А когда программист становится еще опытнее, он начинает понимать, что самого лучшего стандарта кодирования нет и не может быть.
Еще можно говорить о том, чтобы узкая группа, работающая над одним и тем же проектом, соблюдала единоообразие в стиле кодирования.
А как только правила становятся стандартом для всех, тут и начинается — одному такие скобки подавай, другому — другие скобки, одному — префикс Т, другому — префикс С и т.п. И ведь все будут правы.
Re: правильный современный стиль кодирования на C++?
От: dip_2000 Россия  
Дата: 19.09.07 04:27
Оценка:
Здравствуйте, Awaken, Вы писали:

A>ни разу еще не видел хорошего стандарта по кодированию C++



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

Re[2]: правильный современный стиль кодирования на C++?
От: Odi$$ey Россия http://malgarr.blogspot.com/
Дата: 19.09.07 04:48
Оценка:
Здравствуйте, dip_2000, Вы писали:

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



не превратят, факт. Только вот для того чтобы понять насколько этот код осмысленный и в каких местах, времени, за экономию которого так страдает Элджер, понадобится раз в 10 меньше.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Re[2]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 06:32
Оценка:
Здравствуйте, Left2, Вы писали:

L> ... принципиальных возражений не вызывает, разве что за исключением яростной борьбы с венгерской нотацией — нотация-то хорошая, но переусердствовать в ней явно не стоит. К примеру, в 99% случаев переменную лучше назвать strWindowCaption вместо lpctstrWindowCaption или iLineCount вместо uiLineCount.

Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: правильный современный стиль кодирования на C++?
От: Erop Россия  
Дата: 19.09.07 06:47
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist


Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а

Но, тем не менее, я от чего-то похожего на венгерку оставил только префикс C перед именами калссов с нестатическими членами.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: правильный современный стиль кодирования на C++?
От: Erop Россия  
Дата: 19.09.07 07:02
Оценка:
Здравствуйте, Odi$$ey, Вы писали:

OE>

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



OE>не превратят, факт. Только вот для того чтобы понять насколько этот код осмысленный и в каких местах, времени, за экономию которого так страдает Элджер, понадобится раз в 10 меньше.


Понимаешь, правила кодирования бывают двух типов. Бывают неформальные правила, ну например такое: "выбирайте идентификаторы так, чтобы из их названия была ясна их семантика и связь с контекстом использования, если такое название для идентификатора придумать не удаётся, то переформулируйте свой код как-то иначе", а может быть такое, очень легко проверяемое формально: "Все фигурные скобки в программе, за исключением содержимого строковых и сомвольных литералов и комментариев должны находиться на отдельной строке. Открывающая должна находиться ровно под началом имеющеё к ней отношения структуре, а закрывающая строго под открывающей"

Так вот от первых толк бывает, а от вторых совсем редко...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: о фломастерах...
От: CreatorCray  
Дата: 19.09.07 07:14
Оценка:
Здравствуйте, Erop, Вы писали:

CC>>Что впрочем лишний раз подтверждает что на вкус и цвет...

E>...все фломастеры невкусные...
Точно!

E>ИМХО это подтверждает только то, что вы поразному IDE настраиваете. Размер и тип шрифта, цвета и т. д.

не поверишь — default

E>Но, тем не менее, если говорить о читабельности, то большинство ников на rsdn таки в camelCase, ИМХО...

E>Наверное это просто к естественному языку юлиже. ЛогоВАЗ там всякие и CuneiForm
Есть такое.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 07:14
Оценка:
Здравствуйте, Erop, Вы писали:

E>Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а

За что ж тебя так жОстко то?
Впрочем мне после ассиста уже даже в любимом Far + Colorer не так удобно читать. Сильно не хватает find reference
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: о фломастерах...
От: Erop Россия  
Дата: 19.09.07 07:18
Оценка:
Здравствуйте, CreatorCray, Вы писали:

E>>ИМХО это подтверждает только то, что вы поразному IDE настраиваете. Размер и тип шрифта, цвета и т. д.

CC>не поверишь — default
Почему не поверю?
Среды-то разные На одних часто на gcc пишут, а на других на MSVC...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: правильный современный стиль кодирования на C++?
От: Erop Россия  
Дата: 19.09.07 07:20
Оценка:
Здравствуйте, CreatorCray, Вы писали:

E>>Assist есть в IDE, а я, например, часто читаю чужой код в чём-то вроде NotePad'а

CC>За что ж тебя так жОстко то?
Ну код подчинённых, код, присланный на аттестацию, код в соседней подсистеме обычно неудобно открывать в IDE, вполне достаточно и NotePad'а...
Во всяком случае если код нормальный
Просто левый проект долго и нудно открывать в целом...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: А в чём смысл?
От: Erop Россия  
Дата: 19.09.07 07:45
Оценка:
Здравствуйте, Awaken, Вы писали:

Я со всем согласен почти, главное, что рулит не всякие формальные у'роды, а осмысленное именование идентификаторов.

то не согласен откомментил.

A>т.е. JobMonitor а не MonitorJob (если речь о "мониторе" контролирующем какие-то задания)

A>если же Job является первичным то например BlowJob
Это всё хорошо, и в целом просто сводится к рекомендации "изучите английский"
Но в этом причудливом языке часто нельзя сказать что за часть речи мы видим.
Вот, например, LinkMonitor -- это функция или класс

A>это необязательно, но в больших проектах состоящих из многих исходников, защищает от коллизий имен.

A>например есть MMS::Presentation::DataAdapter и MMS::DataAccess::DataAdapter
A>(можно конечно и так: MMS_Presentation и MMS_DataAccess)
Ну в ОЧЕНЬ БОЛЬШИХ может и надо, хотя тут ещё и коллизия имён файлов начнётся, что при использовании каких-нибудь неудобных условий отладки ещё и IDE нагнуть может.
ИМХО лучше конечно избегать разветвлённых иерархий namespaces, кроме того, для совсем совсем потрохов можно использовать nested classes, ну и два ещё замечания.
1) Вообще-то если у двух классов правильно выбранные имена совпадают -- это часто хинт, что возможно это один класс должен быть.
2) В сложных иерархических системах, особенно если они проектировлаись "по месту" обычно очень трудно ориентироваться...

A>в C++ можно писать так:

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


ИМХО так и нужно. Просто оригинальный пост я понял так, что ты предлагаешь camelCase и gcc_style использовать для разделения классов ипеременных.
Правда я бы тут сделал небольшое исключение. Вот всякие public, которые "не public на самом деле" тоже с маленькой буквы

Да и вообще мне всё-таки нраыится правило "потроха с маленькой, морда с большой"
E>>А можно ли написать так, например:
class MyClass 
E>>{ // Это я так понимаю, что ты хочешь такое?
E>>public:
E>>    int Size() const { return size; } // А так можно?
E>>};

A>согласен, это частный случай предыдущего

Я бы всё-таки советовал тебе не заморачиваться на точном следовании расстановки скобок именно так. Предложи все популярные вменяемые паттерны, правда я бы запретил if, for, while и do while без скобок использовать. Чтобы такие косяки не сбивали:
 for( int i = 1; i < size; i++ );
    doItOneTime();


A>>>-аргументы шаблона называем с префиксом T: TArg, TFun

E>>А typedef'ы?

A>typedefы обычно должны нести смысл того типа который они переопределяют.

A>т.е. то же соглашение что для имен классов.

Очень хорошо. И чте же надо написать тут:
template<typename TElement_> class MyArray {
public:
    typedef TElement_ TElement;

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


E>>ИМХО в таком случае можно применять и венгерскую нотацию, если у тебя есть какой-то простой способ порождать на все типы префиксы, потому что иначе ты упрёшься в такую попу:
void processString( myLib1::string sText ) {
E>>    std::string sText( sText ); // Как назвать вторую строку?
E>>    // тут что-то делаем с sText
E>>}


A>зачем это делать? это перегрузка с разными аргументами, но смысл аргументов одинаков, просто представлен разными типами.

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

A>глобальные переменные мы называли с префиксом g_

A>g_Logger;
A>но можно их и не использовать напрямую, а использовать статические методы синглтонов,
A>т.е. Logger::Instance() . тогда проблема именования отпадет
Я неточно выразился. Скорее речь шла о внешних для какого-то куска и внутренних..
Ну да с этим всё понятно в целом.

A>внутренняя реализация (включая локальные и временные переменные) — как угодно на усмотрение разработчика

Ну я бы с известными ограничениями. Я думаю, что надо писать в правилах кодирования два глагола. Скажем "нужно" и "рекомендуется", и соответсвенно во внешних требовать соблюдать всё, а в потрохах только "нужно", а "рекомендуется" по желанию, но какой-то вектор лучше таки задавать. Просто чтобы люди которым всё равно писали одинаково, что удобно для всех.

Ещё, кстати, можно забавить слово "категорическиЗапрещается"

Про спец. комменты тоже правильно. Только ещё классно эти все комменты где-то регить.
Их, кстати, можно оформлять и так:
#pragma hintRefact // тут надо бы переписать то и сё

ТОгда при компиляции будут предупреждения о неизвестной прагме
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: правильный современный стиль кодирования на C++?
От: Erop Россия  
Дата: 19.09.07 07:53
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Я по старой привычке обычно фаром F3 или F4. Тока вот если сурс больше чем 1 файл и есть зависимости туда-сюда то проще его в визжалку загрузить и там побегать. У нас щас принудительно перешли на 2005-ю, но я себе оставил 2003-ю, она куда шустрее бегает, вот ей и открываю все стороннее. Так заодно и основная среда (2005) не засоряется.


Ну фар или NotePad не так уж и разнятся.
А вообще хинт в том, что даже если у тебя есть пять файлов из проекта, где их 1000, то без проекта IDE тебе не поможет
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: правильный современный стиль кодирования на C++?
От: elmal  
Дата: 19.09.07 08:12
Оценка:
Здравствуйте, Awaken, Вы писали:

A>ни разу еще не видел хорошего стандарта по кодированию C++

А тут проблема то не в языке, а то, что изначально не было такого стандарта. В WINAPI так, в MFC по другому, в STL по третьему, в сторонних библиотеках четвертое, а сами пишем еще как-то. Тип может называться myType, TMyType, CMyType, t_my_type, c_myType, k_my_type — вариантов до черта можно придумать . В результате однообразно уже боюсь никак не сделать — наследие. В C# что-то похожее наблюдается, единого стандарта нет (даже если и есть — много кода портируется с Java, а там стиль отличается).
А как стандарт — я просто в восторге от жабовского. Куда не плюнь — везде однообразие, и в стандартных библиотеках, и в сторонних, и в собственных, и в библиотеках и коде разных заказчиков. Если я не ошибаюсь — Java это единственный C подобный язык, для которого стиль четко определен. Я бы подумал над тем, чтобы этот стиль переносить на другие языки, хотя бы частично, думаю имеет смысл его использовать в C подобных языках. Главное чтоб IDE была достаточно удобная, чтобы не было необходимости использовать венгерку, префиксы m_ и т.д.
Re[2]: правильный современный стиль кодирования на C++?
От: Awaken Украина  
Дата: 19.09.07 08:53
Оценка:
>придумать . В результате однообразно уже боюсь никак не сделать — наследие. В C# что-то похожее наблюдается, единого стандарта нет (даже если и есть >- много кода портируется с Java, а там стиль отличается).

в C# как раз стандарт есть. называется Design Guidelines
http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx
как его часть, есть и соглашение об именах:
http://msdn2.microsoft.com/en-us/library/xzf533w0(VS.71).aspx
Re[8]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 08:54
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ну фар или NotePad не так уж и разнятся.

Раскраской синтаксиса как минимум.

E>А вообще хинт в том, что даже если у тебя есть пять файлов из проекта, где их 1000, то без проекта IDE тебе не поможет

Зачастую все же помогает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: правильный современный стиль кодирования на C++?
От: Left2 Украина  
Дата: 19.09.07 10:41
Оценка:
CC>>>Я от венгерки лично для себя оставил только m_ для членов класса. Все остальное в сад. Для того, чтоб узнать тип переменной у меня есть Assist
L>>Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения.
CC>Представь себе, еложу. Я еще и мышыным колесом скролю.
Ну вот — а венгерская нотация позволяет это делать реже за счёт того что основную идею о том какого типа переменная можно понять не елозя мышкой. (Кстати, минусов мне за слово "елозишь" наставили? Не хотел обидеть — просто не нашёл другого слова ).

CC>Информация о типе лично мне нужна только тогда, если из кода нифига не понятна его логика, или она очень сильно завязана на типах.

Логика довольно часто завязана на типы. Не завязана на типы она, пожалуй, в основном только в шаблонном коде. А шаблонного кода обычно в проекте мало или очень мало по сравнению с нешаблонным.

L>>но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.

CC>Мое мнение — префиксы в большинстве своем это рудимент, только засоряющий код. Чтение от их наличия зачастую ИМХО только ухудшается.
Ну вот, а я пытаюсь показать что всё как раз наоборот

CC>А какая свистопляска начинается при смене типа переменной — этож везде где она используется надо имена поменять. А нормальные тулы для рефакторинга для С++ не так уж давно появились.

Но ведь появились же! К тому же — давай рассмотрим чуть подробнее аргумент про изменение типа. Я вижу 2 основных случая — меняется тип локальной переменной или меняется тип переменной — члена класса. В обоих случаях место где используется переменная чётко локализовано (в первом случае — контекст функции или блока, во втором — файлом с реализацией класса). Так что даже банальный Find&Replace в большинстве случаев решает проблему. Реальные проблемы при смене типа начинаются тогда, когда переменная торчит наружу класса как public и используется в системе повсеместно. ИМХО, широкораспространённость такой ситуации говорит о неудачном дизайне.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[6]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 11:33
Оценка:
Здравствуйте, Left2, Вы писали:

L>>>Ты ж не елозишь мышкой (и не бегаешь курсором) по строкам кода по мере чтения.

CC>>Представь себе, еложу. Я еще и мышыным колесом скролю.
L>Ну вот — а венгерская нотация позволяет это делать реже за счёт того что основную идею о том какого типа переменная можно понять не елозя мышкой.
Набор везде по коду префиксов гораздо более трудооемко чем пару раз шевельнуть мышой когда уж очень припрет узнать какой же тип у этой переменной.

L>(Кстати, минусов мне за слово "елозишь" наставили? Не хотел обидеть — просто не нашёл другого слова ).

Нет, думаю за пропаганду "удобности" венгерки.

L>>>но лично моё мнение — префиксы типа перед переменными существенно (настолько существенно, что есть смысл заморачиваться на их написание) увеличивают читабельность кода.

CC>>Мое мнение — префиксы в большинстве своем это рудимент, только засоряющий код. Чтение от их наличия зачастую ИМХО только ухудшается.
L>Ну вот, а я пытаюсь показать что всё как раз наоборот
За это и огреб минусов.

CC>>А какая свистопляска начинается при смене типа переменной — этож везде где она используется надо имена поменять. А нормальные тулы для рефакторинга для С++ не так уж давно появились.

L>Но ведь появились же! К тому же — давай рассмотрим чуть подробнее аргумент про изменение типа. Я вижу 2 основных случая — меняется тип локальной переменной или меняется тип переменной — члена класса. В обоих случаях место где используется переменная чётко локализовано (в первом случае — контекст функции или блока, во втором — файлом с реализацией класса). Так что даже банальный Find&Replace в большинстве случаев решает проблему. Реальные проблемы при смене типа начинаются тогда, когда переменная торчит наружу класса как public и используется в системе повсеместно. ИМХО, широкораспространённость такой ситуации говорит о неудачном дизайне.
Ничего менять не понадобится вообще если нет префиксов. Так что мимо кассы
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: правильный современный стиль кодирования на C++?
От: Left2 Украина  
Дата: 19.09.07 11:34
Оценка:
A>проблема венгерки в том что она не консистентна.
A>она разрабатывалась для Си, где есть только простые типы.
Как так — только простые типы?? А структуры?

A>если следовать этим же правилам в C++ , получается что нужно перед каждым именем переменной-экземпляра класса,

A>писать имя его типа

A>Dick clsDickClintonDick;

A>Job clsJobMonikaJob;

A>бредово и громоздко не правда ли?

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


A>так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна

Честно говоря мне абсолютно пофигу консистентность Мне важна читабельность кода, ничего более.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[4]: С чем именно я не согласен
От: Erop Россия  
Дата: 19.09.07 11:46
Оценка:
Здравствуйте, Left2, Вы писали:

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


1) Простые типы, кроме чисел, в хорошем С++ коде -- редкость.
Вот, например, какой "венгерский" префикс ты используешь для переменной типа std::vector< std::pair<int, std::string> >::itrrator?

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

Короче пользы мало, да ещё и для большинства переменных и не понятно что писать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: правильный современный стиль кодирования на C++?
От: Left2 Украина  
Дата: 19.09.07 11:49
Оценка:
L>>Ну вот — а венгерская нотация позволяет это делать реже за счёт того что основную идею о том какого типа переменная можно понять не елозя мышкой.
CC>Набор везде по коду префиксов гораздо более трудооемко чем пару раз шевельнуть мышой когда уж очень припрет узнать какой же тип у этой переменной.
При наличии Assist-а — ничуть не более трудоёмко. А в отличие от чтения кода, редактирую я его практически всегда в IDE.
Наличие префиксов позволяет быстрее читать код. Присваивание (к примеру) разнотипных переменных бросается в глаза сразу, для этого не надо подводить мышку.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[5]: С чем именно я не согласен
От: Left2 Украина  
Дата: 19.09.07 11:56
Оценка:
E>1) Простые типы, кроме чисел, в хорошем С++ коде -- редкость.
E>Вот, например, какой "венгерский" префикс ты используешь для переменной типа std::vector< std::pair<int, std::string> >::itrrator?
iter. или даже it. Не нужно громоздить префикс полностью описывающий тип. Достаточно — чтобы он давал понятие о типе. Иначе получится майрософтовский lpctstrЧегоТоТам.

E>2) В нормальном С++ коде тип переменных обычно не важен. Случаи, когда таки важен, обычно такие, что хотя бы одна из двух переменных, а обычно обе -- классы какие-то.

вот этого аргумента я не понял.

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

Непонятно что писать — пиши наиболее общий префикс, я так думаю. Ну там к примеру, если это смартпоинтер на что-то — то просто sp будет достаточно. Уже неплохо, по крайней мере видно что код
spMyPtr = NULL;

реально вызывает delete (ну или уменьшает счётчик ссылок), а не просто обнуляет переменную.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[4]: правильный современный стиль кодирования на C++?
От: AndrewJD США  
Дата: 19.09.07 12:14
Оценка:
Здравствуйте, eao197, Вы писали:

E>Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.


у меня наоборот устают от lower_case
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[5]: LinkMonitor -- класс или функция? :)
От: Erop Россия  
Дата: 19.09.07 13:22
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>LinkMonitor — наблюдатель за ссылками

RO>linkMonitor — подключить монитор

Так тоже можно. Суть состоит в том, что хочется по имени формально понимать класс это или функция
E>>Да и вообще мне всё-таки нраыится правило "потроха с маленькой, морда с большой"
Просто регистр первой буквы мне нравится использовать для маркирования степени "внешности" идентификатора.
Так что приходится использовать C
Но это всё вопрос вкуса, конечно

RO>Use the force. Если от нарушения правила становится читабельнее, нарушай. Если приходится часто нарушать, то вряд ли это хорошее правило.

Ну так вот я и говорю, что, ИМХО, занафиг это не надо со скобками...
А если и надо, то есть несколько очевидных контекстов, где недо явно позволить, или, наоборот, запретить писать так илии наче.

RO>+1. Кроме else if, и кроме if(expr); else в макросах.

Ну я бы про else if "рекомендовал" бы использовать фигурные скобки, а для вложенных и для if без else "обязал" бы...

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


Ну мне больше нравится как-то так:
>
char const* name = getSomeName(); 
RO>char const* nameInLoaclCharsetPtr = sSomeNameInLocalCharset(); 
RO>std::wstring nameInLoaclCharSet = wsFromUtf8( nameInLoaclCharsetPtr ); 
RO>


RO>MSVS вроде понимает //TODO, //FIXME и т. п. — отображает их в том же окошке, что и ошибки (предупреждения) компиляции.

А вдруг не MSVS?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: всё за читабельность...
От: Erop Россия  
Дата: 19.09.07 13:32
Оценка:
Здравствуйте, Left2, Вы писали:

L>Правда. Бредово и громоздко. А поэтому — давайте не доводить идею до абсурда. Давайте писАть так:

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


Очень хорошо, а что делать с объектами класса BestPathFinder?
Писать bestPathFinderFirstAttempt и bestPathFinderLastAttempt?

A>>так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна

L>Честно говоря мне абсолютно пофигу консистентность Мне важна читабельность кода, ничего более.

Да? И где вот в таком идентификаторе bestPathFinderNextAttempt где префикс, а где имя?
И легко ли заметить чем он отличается от bestPathFinderNewAttempt?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: правильный современный стиль кодирования на C++?
От: Erop Россия  
Дата: 19.09.07 13:35
Оценка:
Здравствуйте, Left2, Вы писали:

L>Наличие префиксов позволяет быстрее читать код. Присваивание (к примеру) разнотипных переменных бросается в глаза сразу, для этого не надо подводить мышку.


А зачем надо, чтобы это бросалось в глаза сразу?
ИМХО при нормальном дизайне нетирвиальные присваивания разнотипных переменных не компилируются
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: правильный современный стиль кодирования на C++?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.09.07 13:38
Оценка:
Здравствуйте, CreatorCray, Вы писали:

E>>Ну тогда без ложной скромности: http://eao197.narod.ru/desc/lower_case.htm

E>>Главная причина выбора lower_case вместо CamelCase (или camelCase, или Camel_Case) в том, что у меня глаза меньше устают при написании и чтении кода. И, как говорят мои коллеги, не только у меня.
CC>Как по мне так camelCase читается гораздо естественнее. На lower_case у меня глаза ломаюццо

Просто интересно, как вы различаете индентификаторы вроде:
IllegalIndirection


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: С чем именно я не согласен
От: Erop Россия  
Дата: 19.09.07 13:44
Оценка:
Здравствуйте, Left2, Вы писали:

L>iter. или даже it. Не нужно громоздить префикс полностью описывающий тип. Достаточно — чтобы он давал понятие о типе. Иначе получится майрософтовский lpctstrЧегоТоТам.

Да? А для вектора что писать? А для мапа? А для вктора умных указателей?
Я уже не говорю о хмурых шаблонах или классах с длинными именами. Например с таким: CPseudoEroupeanComplexLetterDescriptor

E>>2) В нормальном С++ коде тип переменных обычно не важен. Случаи, когда таки важен, обычно такие, что хотя бы одна из двух переменных, а обычно обе -- классы какие-то.

L>вот этого аргумента я не понял.
Ну в каком контексте надо знать тип переменной, а не её семантику?

L>
L>spMyPtr = NULL;
L>

L>реально вызывает delete (ну или уменьшает счётчик ссылок), а не просто обнуляет переменную.
ИМХО намного лучше, чтобы писать надо было так:
MyData.Delete();
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: правильный современный стиль кодирования на C++?
От: CreatorCray  
Дата: 19.09.07 14:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Просто интересно, как вы различаете индентификаторы вроде:

E>
E>IllegalIndirection
E>

Без проблем
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: всё за читабельность...
От: Left2 Украина  
Дата: 19.09.07 14:18
Оценка:
E>Очень хорошо, а что делать с объектами класса BestPathFinder?
E>Писать bestPathFinderFirstAttempt и bestPathFinderLastAttempt?
bpfFirstAttempt и bpfLastAttempt

A>>>так почему мы для одних типов делаем исключения, а для других нет? нотация не консистентна

L>>Честно говоря мне абсолютно пофигу консистентность Мне важна читабельность кода, ничего более.
E>Да? И где вот в таком идентификаторе bestPathFinderNextAttempt где префикс, а где имя?
E>И легко ли заметить чем он отличается от bestPathFinderNewAttempt?
bpfNextAttempt и bpfNewAttempt — вполне себе неплохо отличаются. Префикс должен быть маленкими буквами и не больше 3-4 букв.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[7]: С чем именно я не согласен
От: Left2 Украина  
Дата: 19.09.07 14:18
Оценка:
L>>iter. или даже it. Не нужно громоздить префикс полностью описывающий тип. Достаточно — чтобы он давал понятие о типе. Иначе получится майрософтовский lpctstrЧегоТоТам.
E>Да? А для вектора что писать? А для мапа? А для вктора умных указателей?
Для любого массива или вектора — arr (поскольку у него семантика массива). Для map и multimap — map. Для set и multiset — set.
Не надо усердствовать и впихнуть всю информацию о типе в префикс Достаточно самого общего понятия.

E>>>2) В нормальном С++ коде тип переменных обычно не важен. Случаи, когда таки важен, обычно такие, что хотя бы одна из двух переменных, а обычно обе -- классы какие-то.

L>>вот этого аргумента я не понял.
E>Ну в каком контексте надо знать тип переменной, а не её семантику?
Вот! Так и я про то же! Префикс должен описывать СЕМАНТИКУ а не весь тип. Чтобы можно было понять — массив это или указатель. К примеру, глядя на
arrFoo = arrBar; // При этом arrFoo может быть вектором, а arrBar - boost::array, или чем-то ещё что работает как массив.

я сразу могу понять что здесь копируется массив, и это возможно длительная и ресурсоёмкая операция. а вот здесь:
pFoo = pBar;

я сразу вижу что это — копирование двух указателей, операция дешёвая и никогда не выбрасывающая исключение.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[6]: правильный современный стиль кодирования на C++?
От: Erop Россия  
Дата: 19.09.07 14:20
Оценка:
Здравствуйте, eao197, Вы писали:

E>Просто интересно, как вы различаете индентификаторы вроде:

E>
E>IllegalIndirection
E>


camelCase и gcc_style требуют разных шрифтов. Это понятно.
Для первого нужен моноширинный шрифт, который всегда с засечками (как, например, в примерах кода на КУВТе )
Для второго можно использовать более компактный Arial, опять же и идентификаторы подлиннее будут.

Но мне традиционно (ещё с FORTRAN'а) нравится моноширинный шрифт -- видно какая же из строчек тут длинная на самом деле
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: правильный современный стиль кодирования на C++?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.09.07 14:22
Оценка:
Здравствуйте, CreatorCray, Вы писали:

E>>Просто интересно, как вы различаете индентификаторы вроде:

E>>
E>>IllegalIndirection
E>>

CC>Без проблем

Счастливчик


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: С чем именно я не согласен
От: Erop Россия  
Дата: 19.09.07 16:08
Оценка:
Здравствуйте, Left2, Вы писали:

L>Для любого массива или вектора — arr (поскольку у него семантика массива). Для map и multimap — map. Для set и multiset — set.

L>Не надо усердствовать и впихнуть всю информацию о типе в префикс Достаточно самого общего понятия.
1) А зачем знать что MyTasks -- это set?
2) А по использованию не видно?

L>Вот! Так и я про то же! Префикс должен описывать СЕМАНТИКУ а не весь тип. Чтобы можно было понять — массив это или указатель. К примеру, глядя на

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


Имхо лучше вместо Foo и Bar выбрать понятные имена. И разу станет ясно долго это копируется или не очень

Ещё, кстати, интересно узнать как ты нотируешь параметры шаблона

Ну, там, например, есть у тебя шаблон Array с параметром TElement. Вот ты переменной типа TElement какой префикс даёшь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: правильный современный стиль кодирования на C++?
От: Аноним  
Дата: 20.09.07 10:01
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Тебе это надо не тут обсуждать, а с теми, кто по нему жить будет.

А>Нету "правильного современного стиля кодирования".
Полностью согласен с Вами.
К тому же кто будет определять "правильность" и "современность" стиля кодирования?
Re[9]: С чем именно я не согласен
От: Left2 Украина  
Дата: 20.09.07 12:38
Оценка:
E>1) А зачем знать что MyTasks -- это set?
К примеру, чтобы понимать что доступ по оператору [] идёт за логарифмическое время.

E>2) А по использованию не видно?

ИМХО в большОм количестве случаев — нет. К примеру — то же самое присваивание выглядит одинаково что для указателей, что для смартпоинтеров что для массивов. Да и контейнеры STL (или им подобные) далеко не всегда можно отличить друг от друга по небольшому куску кода.

E>Имхо лучше вместо Foo и Bar выбрать понятные имена. И разу станет ясно долго это копируется или не очень

Во-1, одно другому не мешает Префиксы совсем не отрицают понятные имена, а только дополняют их. Кстати, понятное имя всё равно будет содержать слово Array — только не в начале а, возможно, в конце или в середине. Ну а во-2 — всегда выбирать понятные имена это из области идеального кода написанного идеальным программистом — к этому безусловно стоит стремиться, но вот получается пока что далеко не всегда.

E>Ещё, кстати, интересно узнать как ты нотируешь параметры шаблона

E>Ну, там, например, есть у тебя шаблон Array с параметром TElement. Вот ты переменной типа TElement какой префикс даёшь?
x, если совсем неизвестен. Или с конкретным префиксом если шаблон можно инстанцировать только чем-то определённым (контейнером, смартпоинтером и т.п.)
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[10]: operator[]
От: Пётр Седов Россия  
Дата: 20.09.07 20:06
Оценка:
Здравствуйте, Left2, Вы писали:
E>>1) А зачем знать что MyTasks -- это set?
L>К примеру, чтобы понимать что доступ по оператору [] идёт за логарифмическое время.
std::set не имеет operator[], он есть у std::map.
Пётр Седов (ушёл с RSDN)
Re[11]: operator[]
От: Left2 Украина  
Дата: 20.09.07 21:02
Оценка:
E>>>1) А зачем знать что MyTasks -- это set?
L>>К примеру, чтобы понимать что доступ по оператору [] идёт за логарифмическое время.
ПС>std::set не имеет operator[], он есть у std::map.

Всё верно, но не суть — идея, я думаю, ясна
... << RSDN@Home 1.2.0 alpha rev. 717>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.