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

M>

M>        std::string
M>             wavOnSearchStarted = "onSearchStarted.wav"
M>            ,wavViaSearching = "viaSearching.wav"
M>            ,wavOnTimeout = "onTimeout.wav"
M>            ,wavOnFound = "onFound.wav"
M>            ,wavOnArchieveStarted = "onArchieveStarted.wav"
M>            ,wavViaArchieving = "viaArchieving.wav"
M>            ,wavOnArchieved = "onArchieved.wav"
M>            ;
M>

M>Может ли кто-то сказать веские аргументы за или против таких объявлений?

Повтори то же самое объявление для указателей на std::string... Я в свое время именно по этой причине отказался от подобных вариантов.

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

Для начала правильно задавайте вопросы,

И конечно подразумевается что для таких вещей и создавался enum,

Или вместо енума гонять каждый разх из функцию в функцию строки ? жуть ...

class soundId
{
   enum idValue
   {
    wavOnSearchStarted,
    wavViaSearching,
    wavOnTimeout,
    wavOnFound,
    wavOnArchieveStarted,
    wavViaArchieving,
    wavOnArchieved
  };

  std::string getFileName(idValue value);// тут централизовано храняться значения имен файлов
};

Прошу прощения, промахнулся кнопкой

R>Для начала правильно задавайте вопросы,
Код должен работать и быть легким в сопровождении в первую очередь, что такое "некрасивый" лично я без понятия.

-Код может быть трудным для чтения и понимания. Тут вы врядли сомжете возразить — читается он на ура
-Некоторые приемы могут быть obfuscating. Да в некотором роде

float a,b;
float a;b;   // конечно человеку это сложно заметить но любой пристойный компилятор выдаст варнинг - аргумент слабый
float *a,b; // можно возразить что указатель относиться к типу а не к экземпляру - ИМХО неплохой аргумент, ошибки тут маловероятны, ptr и value копилятор не перепутает
float **a,*b; // ага - вот это уже лучше - a++, b++ будут работать - весомое возражение если вы часто пользуетесь адресной арифметикой. Но в том то и дело что умные люди перешли на контейнеры.

для интереса я его прогнал через parasoft C++ test — он мне ничего путного не возразил.

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

КР>>Если твой коллега нарушает coding style то бороться следует
M>А если речь идет как раз о его создании и хочется что бы выбор того или иного стиля был максимльно аргументирован?

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

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

M>

M>        std::string
M>             wavOnSearchStarted = "onSearchStarted.wav"
M>            ,wavViaSearching = "viaSearching.wav"
M>            ,wavOnTimeout = "onTimeout.wav"
M>            ,wavOnFound = "onFound.wav"
M>            ,wavOnArchieveStarted = "onArchieveStarted.wav"
M>            ,wavViaArchieving = "viaArchieving.wav"
M>            ,wavOnArchieved = "onArchieved.wav"
M>            ;
M>

M>Экономит что ли...

M>Может ли кто-то сказать веские аргументы за или против таких объявлений?

Такой стиль объявления дает меньше измененных строчек в diff и source control программах.

При изменении, добавлении и удалении элементов объявления.
Не подумайте только что я за такой стиль

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

F>Такой стиль объявления дает меньше измененных строчек в diff и source control программах.

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

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

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

А вообще dangling comma рулит.

You will always get what you always got
  If you always do  what you always did