Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Google Code Style  (Прочитано 13111 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« : 10-07-2008 04:15 » 

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

Пообсуждаем?
Записан

Странно всё это....
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 10-07-2008 08:12 » 

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

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

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

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

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

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #2 : 10-07-2008 10:30 » 

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;
« Последнее редактирование: 10-07-2008 10:31 от Finch » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #3 : 10-07-2008 10:39 » 

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

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

Странно всё это....
npak
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #4 : 10-07-2008 16:28 » new

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

UniTesK -- индустриальная технология надежного тестирования.

http://www.unitesk.com/ru/
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 10-07-2008 19:24 » 

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

Что-то мне кажется сомнительным некоторые из их предложений по именованию. Например, предложения по именованию переменных и функций. Это какая-то смесь стилей, не похожая на классический стиль для C++. Что-то взято от стиля C, а имена функций с большой буквы - по моему это лишняя путаница с типами.
« Последнее редактирование: 10-07-2008 19:35 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 10-07-2008 19:29 » 

Также не понятно, почему запрещают делать логичные и распространенные сокращения типа 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". По крайней мере - в пределах модуля.
« Последнее редактирование: 10-07-2008 19:35 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #7 : 11-07-2008 03:45 » 

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

Я обычно если внутри функции приходится более одного раза(а то и один раз Улыбаюсь ) делаю typedef или получаю ссылку
например:
Код:
SomeClass & sc = GetMainClass().GetHolder(2).GetSomeClass();
typedef BaseClass::Nested::DataHolder::Container::Iterator Iterator;

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

Осталось постараться следовать рекомендациям Улыбаюсь
Записан

Странно всё это....
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #8 : 11-07-2008 06:25 » 

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 и т.п.
« Последнее редактирование: 11-07-2008 06:29 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #9 : 11-07-2008 09:05 » 

разумно, но в таком случае я бы их сложил в структуру 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
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 11-07-2008 09:50 » 

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #11 : 11-07-2008 10:10 » 

Цитата
P.S. Все наши беды от пуговицы
Скорей всего, что-то надо менять в консерватории  Улыбаюсь
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #12 : 14-07-2008 04:14 » 

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

Странно всё это....
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines