Google Code Style

[Антон (LogRus)]

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Пообсуждаем?

[npak]

Начал читать. Много разумных рекомендаций из различных учебников собраны в одном месте.

В самом начале нашел потенциальный источник труднообнаружимых ошибок. Рекомендуют использовать побольше forward declaration и поменьше включений стронних файлов. В принципе, если используются декларировать только имена классов, то ничего фатального случиться не должно. Им бы запретить делать forward declaration функций и глобальных переменных.

Я однажды так попал - в очередной версии разработчики изменили тип переменной, причем новый тип занимает в памяти меньше места. Это изменение внесли в заголовочный файл, а декларация в другом заголовочном файле осталась без изменений. в результате из разных мест программы к этой переменной обращаются по-разному, и портится соседняя память. Испорченная соседняя память давала самые разные эффекты, почти произвольные. Ошибку искали четыре дня. Потом долго разговаривали о том, что так писать нельзя. Разговаривали, понятно, матом

аналогичные проблемы были как-то раз с функцией - авторы поменяли порядок аргументов в основном заголовке, а в forward declarations забыли.  Хорошо, что у нас были сорсы, и в отладчике сразу увидели, что аргументы стали другими, а без этого искали бы пару дней.

Резюме: я бы поостерегся делать forward declarations пока не уверен на 200% процентов, что изменений не будет.

[Finch]

npak, скорее всего они имели ввиду технику, которую я увидел в первый раз в учебнике по Qt, что то типа этого

Код:

#include <QMainWindow>

class QAction;
class QMenu;
class QLabel;
class QHBoxLayout;
class QVBoxLayout;
class QPushButton;



class MainWindow: public QMainWindow
{
   Q_OBJECT
public:
      MainWindow();
.......
QAction *fileNew;
QAction *fileSave;

[Антон (LogRus)]

Finch, согласен
полезная техника, позволяет убрать лишние зависимости при компиляции файлов

Про глобальные переменные и функции есть отдельная строка.

[npak]

Я тоже так понял.  Но ! Законы мерфи еще никто не отменял, поэтому писать инструкции нужно для идиотов. В данном случае сказать открытым текстом: делай forward declaration классов, структур, юнионов, и только их. Никакие другие сущности декларировать нельзя.

[RXL]

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Naming

Что-то мне кажется сомнительным некоторые из их предложений по именованию. Например, предложения по именованию переменных и функций. Это какая-то смесь стилей, не похожая на классический стиль для C++. Что-то взято от стиля C, а имена функций с большой буквы - по моему это лишняя путаница с типами.

[RXL]

Также не понятно, почему запрещают делать логичные и распространенные сокращения типа count -> cnt.

Abbreviations

Do not use abbreviations unless they are extremely well known outside your project. For example:

// Good
// These show proper names with no abbreviations.
int num_dns_connections;  // Most people know what "DNS" stands for.
int price_count_reader;   // OK, price count. Makes sense.

// Bad!
// Abbreviations can be confusing or ambiguous outside a small group.
int wgc_connections;  // Only your group knows what this stands for.
int pc_reader;        // Lots of things can be abbreviated "pc".

Never abbreviate by leaving out letters:

int error_count;  // Good.

int error_cnt;    // Bad.

С длинными названиями просто повеситься можно - рано или поздно понимаешь, что их стоит сократить. Порой приходится раз 50 и более в одном модуле упоминать такое имя. Т.ч. я за "pc_reader" против "price_count_reader". По крайней мере - в пределах модуля.

[Антон (LogRus)]

С длинными названиями просто повеситься можно - рано или поздно понимаешь, что их стоит сократить. Порой приходится раз 50 и более в одном модуле упоминать такое имя. Т.ч. я за "pc_reader" против "price_count_reader". По крайней мере - в пределах модуля.

Я обычно если внутри функции приходится более одного раза(а то и один раз ) делаю typedef или получаю ссылку
например:

Код:

SomeClass & sc = GetMainClass().GetHolder(2).GetSomeClass();
typedef BaseClass::Nested::DataHolder::Container::Iterator Iterator;

В остальном, как не парадоксально почти со всем согласился хотел поспорить про исключения но почитал комментарий и понял, что оправдано.

Осталось постараться следовать рекомендациям

[RXL]

LogRus, я не о таких именах, а о приватных членах класса с длинными именами. Например: installation_type я успешно сокращаю в instType без потери смысла.

Вот еще пример. Есть в структуре имя, которое должно означать "воздушно-кабельный переход". Подходящий перевод - cable pole line. Получилось cable_pole_line. Но полей с этим префиксом много: cable_pole_line_build_id, cable_pole_line_amount, cable_pole_line_length и т.п. Куда проще сделать одно сокращение и комментарий с пояснением: cpl_build_id и т.п.

[Антон (LogRus)]

разумно, но в таком случае я бы их сложил в структуру cable_pole и использовал бы ссылку нас структуру
впрочем сам не без греха вот такие штуки instType использую.

Там в конце есть комментарий:

Existing Non-conformant Code
▽ You may diverge from the rules when dealing with code that does not conform to this style guide.
link

If you find yourself modifying code that was written to specifications other than those presented by this guide, you may have to diverge from these rules in order to stay consistent with the local conventions in that code. If you are in doubt about how to do this, ask the original author or the person currently responsible for the code. Remember that consistency includes local consistency, too.

[Dimka]

Куда проще сделать одно сокращение и комментарий с пояснением: cpl_build_id и т.п.

В пределах одной функции - да. А если это начнёт расползаться по разным файлам, то кто потом найдёт этот твой комментарий?

P.S. Все наши беды от пуговицы

[Sla]

P.S. Все наши беды от пуговицы

Скорей всего, что-то надо менять в консерватории 

[Антон (LogRus)]

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