Вот конвенции кода гугла.
Как вам? Кто-нибудь использует? Или есть какие-то другие более распространенные? Например мелкомягких?
Дискасс

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

N>Вот конвенции кода гугла.
N>Как вам? Кто-нибудь использует? Или есть какие-то другие более распространенные? Например мелкомягких?
N>Дискасс

256 обсуждали уже, воспользуйся поиском, плиз.

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

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

N>Вот конвенции кода гугла.
N>Как вам? Кто-нибудь использует? Или есть какие-то другие более распространенные? Например мелкомягких?
N>Дискасс

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

We do not use C++ exceptions.

All parameters passed by reference must be labeled const

Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h.

Use cpplint.py to detect style errors

З.Ы.: Если отбросить Symbian-специфику связанную с управлением памятью, самые продуманные плюсовые соглашения были ИМХО на нем.

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

AK>

All parameters passed by reference must be labeled const

что тут нелепого?

AK>

Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h.

не совсем понимаю, о чем тут хотят сказать %)

и да, С++ без исключений — это сильно =)

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

X>и да, С++ без исключений — это сильно =)
Да ничего сильного в этом нет. Ну и вообще не проблема, но это
1) Тут уже не раз обсуждалось
2) Как показали те обсуждения, тут то, что можно жить и так не до всех таки доходит

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

X>Здравствуйте, artem.komisarenko, Вы писали:

AK>>

All parameters passed by reference must be labeled const

X>что тут нелепого?

bool do(T & result)
{
  bool status = false;

  ...

  return status;
}

void do(T const & source, T & destination)
{
  ...
}

К слову, фраза про недопущение неконстантной ссылки у них была еще даже до C++11 с его move'ми. По ихнему феншую оно должно вот так выглядеть:

bool do(T * result)
{
  bool status = false;
  if (result)
  {
    ...
  }

  return status;
}

void do(T const & source, T * destination)
{
  if (destination)
  {
    ...
  }
  else
  {
    // ну и чё делаем или ничё не делаем?
  }
}

AK>>

Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h.

X>не совсем понимаю, о чем тут хотят сказать %)

Они хотят:

#include <cstdlib>
#include <string>
#include <boost/cstdint.hpp>
#include "MyClass.h"

X>и да, С++ без исключений — это сильно =)

Вот-вот. Даже Symbian до такого не доходил, у них свой аналог был.

22.10.2013 14:22, Erop пишет:
> 2) Как показали те обсуждения, тут то, что можно жить и так не до всех
> таки доходит
Можно вообще на С писать или вообще на асме.

Здравствуйте, Erop,

E>Да ничего сильного в этом нет. Ну и вообще не проблема, ....

Угу. Прости-прощай new, теперь будет malloc/free наше все. И да, прости-прощай вся std::, бо и из нее может ненароком вылететь исключение. RAII запихиваем в глухой забытый угол винчестера...
Религиозное неприятие исключений такое религиозное.

22.10.2013 14:34, Vlad_SP пишет:

> Религиозное неприятие исключений такое религиозное.
Почему религиозное, может и специфическое железо ограничения накладывать.
Но, соглашусь, что в 99% это религия.

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

V_S>Угу. Прости-прощай new, теперь будет malloc/free наше все.
открой для себя таки new(nothrow)


V_S>И да, прости-прощай вся std::, бо и из нее может ненароком вылететь исключение.
Ну, во-первых, вовсе и не вся.
А, во-вторых, ну и слава Богу.

V_S>RAII запихиваем в глухой забытый угол винчестера...
Тоже нет нужды. Просто у раи-обёрток появляется метод типа IsSuccessBuilded()...

V_S>Религиозное неприятие исключений такое религиозное.
Религиозное-то да. Так же, как и религиозное принятие.
тут уже был таки флейм и не один на тему...

22.10.2013 14:45, Erop пишет:

> открой для себя таки new(nothrow)
Икемефулы на тебя нет (пора призывать). А так спасибо, мы все тут и не
знали, глаза открыл.

> V_S>Религиозное неприятие исключений такое религиозное.
> Религиозное-то да. Так же, как и религиозное принятие.
Да нет, если что-то можно написать проще и лаконичнее, то разумно этим
воспользоваться. А вот ограничивать себя подобным образом — это уже религия.

Здравствуйте, Vzhyk,

согласен, железо может накладывать такие ограничения. Но в таком специфическом случае безоговорочное принятие Google code conventions — это уже в чистом виде карго-культ, нет?

22.10.2013 14:53, Vlad_SP пишет:

> согласен, железо /*может*/ накладывать такие ограничения. Но в таком
> специфическом случае безоговорочное принятие Google code conventions —
> это уже в чистом виде карго-культ, нет?
Конечно. Лично я вообще противник подобных convention.
Но, в программировании в С++ разумны некоторые правила:
1. По возможности не пользоваться голыми указателями, кроме необходимости.
2. По возможно использовать const, где нужно.
3. По возможности не использовать gotо, кроме необходимости.
Больше и не придумаю.

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

N>Дискасс

http://www.rsdn.ru/forum/flame.comp/4686354

Автор: Marty
Дата: 03.04.12

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

V>воспользоваться. А вот ограничивать себя подобным образом — это уже религия.
ну гугловоды же объясняют обоснование своих соглашений? В частности отказ от исключений они объясняют тем, что готовность кода к исключениям — неверефицируемое и необеспечиваемое свойство кода, а им важна надёжность и дешёвый релиз

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

V_S> RAII запихиваем в глухой забытый угол винчестера...

А RAII вам зачем?

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

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

V_S>>Угу. Прости-прощай new, теперь будет malloc/free наше все.
E>открой для себя таки new(nothrow)

Только вот писатели c++ кода для гугла его похоже еще не открыли. Во всяком случае, когда я был вынужден воспользовался protocol buffers, там никаких nothrow не было, просто new и без всяких попыток ловить исключения хоть где-нибудь.

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

E>ну гугловоды же объясняют обоснование своих соглашений? В частности отказ от исключений они объясняют тем, что готовность кода к исключениям — неверефицируемое и необеспечиваемое свойство кода, а им важна надёжность и дешёвый релиз

а вызов IsSuccessBuilded кто верифицирует и обеспечивает?

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

R>Только вот писатели c++ кода для гугла его похоже еще не открыли. Во всяком случае, когда я был вынужден воспользовался protocol buffers, там никаких nothrow не было, просто new и без всяких попыток ловить исключения хоть где-нибудь.

Может у них ::operator new перекрыт?..

Во всяком случае, я как-то писал им один-другой классец, так в том окружении, для которого я писал он был перекрыт каким-то своим хитровывернутым изделием...

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

A>а вызов IsSuccessBuilded кто верифицирует и обеспечивает?

В смысле?
Положим у нас есть какой-нибудь NothrowFile, и у него есть IsOpen()
Скажем, если мы пытаемся читать из неоткрытого файла, то нам вернут код ошибки и "прочитают" 0 байт...

В целом на С как-то же писали без исключений?.. Не так уж и сложно. Что-то упрощается, что-то усложняется, но в целом глобально, связанность кода без исключений становится меньше, ошибки локализуются проще и т. д...

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