Qt Coding Style

    Qt Coding Style по версии Qt
    Привет, хабражители!

    Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.

    Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше…


    Постулат №1. Выравнивание


    В Qt принято использовать отступы по 4 пробела. Но именно 4, и именно пробела. Использовать \t или другую ширину пробелов считается ужасно плохим тоном и жестоко карается.

    Постулат №2. Объявление переменных


    Один из самых важных постулатов, так как определяет читабельность и общий стиль кода. Правила объявления переменных собраны в такой список:

    • Объявлять каждую переменную на отдельной строчке
    • Избегать коротких или немногословных названий (например «a», «rbarr», «nughdeget»)
    • Дождитесь, пока переменная будет нужна, и только тогда объявляйте ее
    • Функции и переменные должны быть в camelCase
    • Избегайте аббревиатур и всяческих сокращений
    • Классы всегда должны начинаться с заглавной буквы
    • Публичные классы должны начинаться с буквы ‘Q’ (QRgb), затем заглавная буква
    • Публичные функции должны начинаться с буквы ‘q’ (qRgb)
    • Аббревиатуры должны быть в PascalCase (например QXmlStreamReader вместо QXMLStreamReader)

    // Неправильно
    int a, b;
    char *c, *d;
         
    // Правильно
    int height;
    int width;
    char *nameOfThis;
    char *nameOfThat;
    

    // Неправильно
    short Cntr;
    char ITEM_DELIM = '\t';
         
    // Правильно
    short counter;
    char itemDelimiter = '\t';
    


    Постулат №3. Пробелы


    Пробелы — очень важный элемент форматирования исходного кода. Он отыгрывает очень большую роль в читабельности кода.

    • Используйте пробелы для группировки отдельных сегментов кода
    • Для разделения можно использовать только одну пустую линию
    • Всегда использовать только один, и только один пробел после ключевого слова и фигурной скобки
    • Для указателей и ссылок, всегда используйте один пробел между типом и ‘*’ или ‘&’, но никогда не ставьте пробел между ‘*’ или ‘&’ и названием переменной
    • Окружайте бинарные операторы пробелами
    • Никаких пробелов после приведения типов
    • Старайтесь избегать С-подобных приведений

    // Неправильно
    if (foo){
    }
         
    // Правильно
    if (foo) {
    }
    

    char *x;
    const QString &myString;
    const char * const y = "hello";
    
    MyClass *obj = new MyClass(this);
    bool ok;
    obj.report(1, &ok);
    

    // Неправильно
    char* blockOfMemory = (char* ) malloc(data.size());
    QTextStrem newOne(..);
    newOne<<"Hello"<<","<<" "<<"world";
         
    // Правильно
    char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()));
    QTextStrem newOne(..);
    newOne<< "Hello" << "," << " " << "world";
    


    Постулат №4. Скобки


    Скобки — это вообще отдельная тема. Они, как и пробелы, отыгрывают львиную долю во внешнем виде и читабельности кода

    • В качестве основного правила, левая фигурная скобка находится на той же строчке, что и оператор:
    • Исключение: Реализация функций и объявления классов всегда, абсолютно всегда располагают левую скобку на новой строчке:
    • Используйте фигурные скобки когда тело условия содержит более одной линии, и если однострочный оператор — что-то комплексное
    • Исключение 1: Также используйте скобки если родительский оператор занимает несколько линий или оберток
    • Исключение 2: Также используйте скобки в if-else блоках где if-код или else-код занимает несколько линий
    • Используйте фигурные скобки когда тело оператора — пустое

    static void foo(int g)
    {
        qDebug("foo: %i", g);
    }
    
    class Moo
    {
    public:
        Moo();
        Moo(int a, int b);
    
    public slots:
        int getResult();
    
    protected slots:
        void processNumbers();
    
    private:
        int mineA;
        int mineB;
        int mineResult;
    };
    

    // Неправильно
    if (address.isEmpty()) {
        return false;
    }
    for (int i = 0; i < 10; ++i) {
        qDebug("%i", i);
    }
           
    // Правильно
    if (address.isEmpty())
        return false;
           
    for (int i = 0; i < 10; ++i)
        qDebug("%i", i);
    

    // Неправильно
    while (a);
    if (expression)  else
        // do something
    
    // Правильно
    while (a) {}
    if (expression) {
    } else {
        // do something
    }
    


    // Неправильно
    if (codec)
    {
        // do something
    }
         
    // Правильно
    if (codec) {
        // do something
    }
    

    // Неправильно
    if (address.isEmpty())
        return false;
    else {
        qDebug("%s", qPrintable(address));
        ++it;
    }
    
    // Правильно
    if (address.isEmpty()) {
        return false;
    } else {
        qDebug("%s", qPrintable(address));
        ++it;
    }
    
    // Неправильно
    if (a)
        if (b)
            ...
        else
            ...
    
    // Правильно
    if (a) {
        if (b)
            ...
        else
            ...
    }
    

    // Неправильно
    if (address.isEmpty() || !isValid()
        || !codec) 
        return false;
    
    // Правильно
    if (address.isEmpty() || !isValid()
        || !codec) {
        return false;
    }
    


    Постулат №5. Круглые скобки


    Используйте круглые скобки чтобы группировать выражения:
    // Неправильно
    if (a && b || c)
    if (a + b & c)
    
    // Правильно
    if ((a && b) || c)
    if ((a + b) & c)
    


    Постулат №6. Условия множественного выбора switch


    Безусловно, эти условия причина многих дискуссий со стороны разработчиков и создателей Coding Guidelines — там может быть очень много различных вариантов. Однако Qt предлагает именно такой вариант:

    • Операторы case должны находиться в той же колонке, что и оператор switch
    • Каждый случай должен заканчиваться оператором break (или return) или комментарием, чтобы показать чтоe далее следует другой случай


    switch (myEnum) {
    case Value1:
        doSomething();
        break;
    case Value2:
    case Value3:
        doSomethingElse();
        // fall through
    default:
        defaultHandling();
        break;
    }
    


    Постулат №7. Разрыв строк


    Часто происходит следующее: есть разработчик Вася с большим монитором. Он пишет себе код спокойно. Потом этот код открывает разработчик Петя, с ноутбуком, и прозревает — ему приходится много скроллить чтобы прочитать весь код. Это один из дефектов читабельности. Что же предлагает Qt для спасения?

    • Старайтесь чтобы строки были не длиннее 100 символов; обрывайте их, если это необходимо
    • Коммы располагаются в конце оборванной строки; операторы следует переносить в начале новой строки. Оператор в конце строки очень просто не увидеть если ваш редактор слишком узкий

    // Неправильно
    if (longExpression +
        otherLongExpression +
        otherOtherLongExpression) {
    }
    
    QMessageBox::information(d->someObjectWithLongName, tr("A long title for mesage"), tr("A very very very very very very long body", QMessageBox::Ok, QMessageBox::Cancel);
    
    // Правильно
    if (longExpression
        + otherLongExpression
        + otherOtherLongExpression) {
    }
    
    QMessageBox::information(d->someObjectWithLongName,
                                                      tr("A long title for mesage"),
                                                      tr("A very very very very very very long body", 
                                                      QMessageBox::Ok, QMessageBox::Cancel);
    

    UPD: последний участок кода отображается неверное — там все строчки должны быть на одном уровне

    Постулат №8. Наследование и ключевое слово `virtual`


    В этом постулате все предельно просто — главное не писать `virtual` перед названием переопределяемого метода в .h файле.
    // Неправильно
    class MyWidget : public QWidget
    {
    ...
    protected:
        virtual void keyPressEvent(QKeyEvent *);
    
    // Правильно
    class MyWidget : public QWidget
    {
    ...
    protected:
        void keyPressEvent(QKeyEvent *);
    


    Постулат №9. Общее исключение


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

    К сожалению, я не смог найти примера, когда Qt Coding Guidelines делают код — уродливым.

    Завершение


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

    Для меня — Qt Coding Style просто идеальный стиль для написания кода. Я считаю его чистым, удобным, приятным. За все время его использования у меня не возникло никаких проблем с читабельностью кода. Буду ли я его рекомендовать? Конечно, да! Тем более, я считаю что именно его и надо пропагандировать всем новичкам на платформе Qt.

    Спасибо за внимание.
    Поделиться публикацией

    Похожие публикации

    Комментарии 109
      +4
      Спасибо за проведенную работу. Пускай здесь же будет QML Coding Conventions: qt-project.org/doc/qt-4.8/qml-coding-conventions.html
        +1
        Спасибо за линк. Сейчас как раз начал потихоньку осваивать кумль — очень в тему,
        +5
        Постулат №8 — но почему?!
          0
          Рискну предположить, что virtual должен показывать, что метод может быть переопределен в подклассах вашего класса. Если вы не планируете, что от вашего класса будут наследоваться, то писать virtual не следует. Поскольку ваш класс уже наследован от другого класса с виртуальным методом, метод в вашем классе будет виртуальным в любом случае. Кстати, Qt Creator (официальная среда разработки для Qt) показывает виртуальные методы курсивом, так что наглядность не страдает.
            0
            Т.е. постулат следует читать так...?
            В этом постулате все предельно просто — главное не писать `virtual` перед названием переопределяемого метода в .h файле, если вы наследуете один из классов Qt.
              0
              Нет, классы Qt тут ни при чем. Скорее так: «если не предполагается, что этот метод может быть переопределен в подкласах вашего класса».
                0
                Откуда такая глубокая мудрость может быть у автора класса? Т.е. если метод изначально был виртуальным уже в базовом классе, то что заставляет твердо верить, что его никто не будет переопределять после вас?
                  0
                  Вы говорите в разрезе контрибьютинга?
                    0
                    Я говорю в разрезе повторно используемого кода (например, вами же, но через полгода).
                    Еще раз: мое удивление вызвал «постулат №8» тем, что действительно полезное (ОК — пусть только в ряде случаев) слово virtual «запрещается» писать. Очень хочется понять причину этого «запрета» — чем это слово вредит-то?
                    Остальные «постулаты» можно как-то обосновать (хотя и с ними иногда тянет поспорить). Но этот — вообще за гранью моего понимания.

                    P.S. По поводу правила «Публичные классы должны начинаться с буквы ‘Q’ ». Была такая замечательная книжка Голуба «Правила программирования на С++». И там этот же аспект рассматривался с точки зрения библиотеки MFC (где, как известно, все публичные классы начинались с буквы 'C' — «class»). Почти дословно: «Если вы назовете свой класс по этому правилу, а в следующей версии MFC Microsoft выпустит свой класс с таким же именем, угадайте — кому придется менять код?».
                      0
                      Насчет пункта со словом virtual — это отдельная тема.

                      А говоря про «Публичные классы должны начинаться с буквы ‘Q’ » — это было написано в разрезе контрибьютинга. Если вы работая в Qt хотите назвать класс на Q — следует поменять название.
                        0
                        Есть же неймспейсы для этого.
                          –1
                          Честно говоря, я не самый ярый фанат неймспейсов в этом плане. Как по мне лучше назвать класс QcsClass, чем Library::QClass.
              +4
              Я не вижу зла в том, чтобы напомнить лишний раз людям — метод виртуальный.
              А вот если вы соблюдаете правила по написанию имен из Qt, то определить сходу для незнакомого метода его полиморфность — на мой взгляд, дорогого стоит. Особенно для того человека, который чуть позже будет наследовать класс от вашего, а не от базового из Qt.

              Кстати, а для виртуальных деструкторов это правило действует? Там тоже слово virtual чем-то мешает?
            +5
            Тоже возник вопрос по 8 постулату, всегда пишу virtual, что бы отличать, что метод от базового класса
              0
              Ну придумали они так, совершенно никакого смысла в этом нет. В C++11 предпочтительно использовать override, и отказаться от virtual в имени ибо будет уже избыточно.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Спасибо. Перевод прочитал — отлично!
              +1
              Кажется, постулат 7 в статье выглядит немного не так, как Вы задумывали… Вы наверное имели ввиду это?
                0
                Хотя как мне кажется если параметров много то лучше вообще каждый параметр переносить на новую строку…
                0
                Очень напрягает, что в каждом фреймворке или библиотеке свой стиль написания. Особенно если с несколькими библиотеками работают в одном месте.
                В PHP сейчас работают над единым PSR-2. Пока что приняли только PSR-0.
                  +1
                  Замечательно тем, кто использует только один фреймворк. Вот я например, использую для дева софта только Qt — и в полном восторге от Qt Coding Style.
                    +1
                    А как можно один фреймворк/библиотеку использовать?
                    Вот допустим вы решили использовать FANN вместе с Qt.
                    Опа: разные стили написания.
                      0
                      Угу, а что делать если вдруг решили использовать другоя язык (например Delphi), опа; разный синтаксис… Использование только одного языка/фреймворка — это нормально.
                        0
                        Нормально для проекта какого уровня? Qt слишком слабый фреймворк, чтобы довольствоваться лишь им. Вообще, те кто пишут на C++, как правило, используют несколько фреймворков.
                          0
                          Выражение «Qt слишком слабый фреймворк» строго говоря, не очень точно. Qt — достаточно мощный фреймворк. Но он, конечно же, не универсальный и иногда вместе с ним нужно использовать и другие библиотеки. Тогда, конечно, разных стилей не избежать. Другое дело, что в больших проектах работа делиться между разработчиками (или командами) и тогда вполне может быть, что один человек пишет свою часть только на Qt в стиле Qt, а другой работает над какой-то другой библиотекой в её стиле. Смешение стилей возникает только на стыке этих компонентов, но этот стык, при правильной архитектуре, не такой уж и большой, так что можно жить.
                            0
                            Мощный в чем? В раздутости? Да, согласен. В эффективности и функционале? Увольте.
                            RegExp до Qt5 был убог до невозможности.
                            QNetwork в WIndows построен не на comepletion port
                            XSLT все в экспериментах.
                            И т.д. Я не могу вспомнить всё сразу, только самое яркое.
                            Qt отличный GUI framework не для слабых душой(ибо покостылить придется знатно) в котором остальные части билиотеки, как правило, уступают своим аналогам, специализирующимся на конкрентных вещах.
                              0
                              Я вообще-то согласился с Вами на счёт необходимости использования сторонних библиотек.
                            +1
                            Ну как сказать, У меня на компе валяется 40 000 кода С++ движка (в процессе разработки), который вообще без фреймворков написан. И жить хуже от того не стало. Хотя нет, вру, он для редактора уровней тянет за собой Qt, но по умолчанию, для самой игры он там не нужен будет.

                            Qt — очень сильный и качественный фреймворк. Даже не знаю, почему вы его называете слабым… Объясните?

                            Вообще, те кто пишут на C++, как правило, используют несколько фреймворков.
                            Нет такого правила)). И мне кажется, что если у вас есть такая статистика — скорей всего она основана на нерепрезентативной выборке.
                              0
                              Если Вы написали 40000 без фреймворков, не значит, что нельзя было написать 10000 с оными. Тут не о чем говорить, я Вашего кода не видел. Но те, кто пишут 40к без, хотя бы, буста вызывают у меня подозрение.
                                0
                                Тем более без boost. Логика такова, что в случае наличия какого либо дефекта, с высокой долей вероятности нужно будет спускаться до самых низов. При использовании boost низами будут исходники boost, от чтения которых люди впадают в депрессию.

                                К тому же, классы контейнеров с нужными алгоритмами, type traits, in-place constructor и прочими весомо полезными фичами весят 2000-3000 строк кода. Сеть для разных платформ еще 1000-2000. Потоки около тысячи… В общем, не все так печально. Все достаточно быстро и выигрыш при boost-е был бы порядка 10 000 строк кода, 1-2 месяца, что не является очень высокой платой за счастье.

                                Другими словами, в этом проекте построен микрофреймворк Gaia, который;
                                1. На порядки меньше буста
                                2. В среднем не медленне буста.
                                3. Очень легко читается и дебажится.
                                4. Лишен мусора.
                                  +1
                                  Не забудьте добавить: протестирован на порядки меншье буста.
                                  Использовать велосипеды это конечно прикольно, но, на моей практике, ни разу себя не оправдало. Может у Вас другая практика, тогда я рад за Вас.

                                  P.S. Непонимание внутренностей буста интересная отговорка, сколько им пользуюсь а внутрь лезть приходилось не часто. И дебажить мне его не надо, благо для этого есть сотни тысяч «тестеров».
                                    +1
                                    Скорей всего дефектов больше, чем в бусте. Но, с высокой долей вероятности, в целом в программе меньше дефектов, чем было бы при использовании буста. С бустом у меня проблем особо не возникало, но гордится хотябы 10% процентом понимания буста я не могу. И время затреченное на то, чтобы получить это понимае, подозреваю было бы большим нежели написание собственного фреймворка.

                                    Я являюсь участником проекта, не лидером. Лидер работает сейчас в Ubisoft, игры которого сделаны на С++ без boost.
                                      +1
                                      Ходят слухи, что в gamedev наиболее отвратный код во всей индустрии в силу малого жизненного цикла игр. Я не знаю правда ли это, но причина звучит вполне разумна.
                                      К тому же место работы человека не говорит ни о его способностях ни о качестве его кода, к сожалению.
                                        +1
                                        В gamedev по разному бывает. Где-то весь проект — гадость, где-то все хорошо.
                                        Там я просто указал, на авторитет юбисофта, который без буста.
                                          +1
                                          Я понял, просто Ubisoft можно считать авторитетом в издательстве игр(спорно), но вот в качестве качества кода(а следовательно и его корректности) Ubisoft, для меня, не больший авторитет чем любая другая компания чей софт периодически дает сбои.
                                          Любой софт дает сбои, чей-то больше, чей-то меньше. Ubisoft на этом фоне никаким качественным образом не выделяется.
                                0
                                Про слабость чуть выше ответил.
                                  +1
                                  QNetworkAccessManager — мусор, ну я так думаю по меньшей мере. Еще там есть кучи платформо-зависимых методотов и классов. Ну еще всякого мелкого… Но все-же позитива в нем намного больше и с каждим разом все больше и больше.
                      –1
                      Мне кажется такой стиль противоречит стандартному стилю C++ (я про названия классов и переменных с большой буквы). И если в таком коде использовать что-то из stl или boost или из стандартной библиотеки С — то все будет выглядеть очень криво. Не понимаю, что заставило создателей писать библиотеку в таком стиле.
                        +4
                        В С++ нет стандартного стиля.
                          0
                          Да стандартного нет. Я имел ввиду тот, что в стандартной библиотеке.
                            +3
                            Стандартная библиотека просто унаследовала C-style, который является UNIX-style. Буст пошел по тому же пути. Далеко не всем нравится такой стиль, и мы можем видеть это на примере таких известных C API как: WinAPI, Xlib, Carbon. Все они используют camel в именовании, с начальной заглавное буквой. Более того, если посмотреть на индустрию в целом(C#, Java и т.д.), то можно заметить, что «ООП» языке имеют склонность именно к camel, чем к C-style. С++ хочет быть ближе к ООП, чем к своему прародителю С. Именно поэтому очень многие библиотеки используют camel-style, что, лично я считаю, правильным вектором.
                        0
                        Смущают постулаты 4 (в части расположения фигурной скобке на той же строке с if-ом) и 6…
                          0
                          постулат 4 это т.н. «египетские скобки» или K&R стиль
                            0
                            Пусть 4 — вопрос вкуса, но 6 то чем не угодил?
                              0
                              Лично я считаю, что case должны иметь отступ относительно switch, ибо являются его частью, а не отдельной равной структурой.
                                0
                                case это всего лишь метки (labels). сам по себе блок switch сквозной внутри.
                                  0
                                  Они метки ВНУТРИ switch-а. Я и метки для goto ставлю так, чтоб он был на уровне кода, обычно обрамляю только пустыми строками сверху и снизу. Правда уже и не помню, когда в последний раз использовал goto… Да и то ассемблер помом был.
                                    0
                                    Но так получается, что рабочий код внутри switch'а на две позиции смещён. Что не логично.
                                      0
                                      А по мне логично как раз…
                                        0
                                        Код внутри обычного блока, вне зависимости от меток, смещается на один уровень. А тут на 2. Где же логика?
                                          0
                                          Просто в switch-ах, я метки за метки не считаю. Это как подблоки для меня.
                                –1
                                Если речь о необходимости комментариев //fall through, то логично предположить, что разбирая чужой switch ты не можешь знать, забыли здесь break или return, или так задумано.
                                Это тот же принцип, по которому все кейсы выхода из функции должны быть с return (если функция не возвращает void, конечно).
                                  0
                                  Нет, не об этом, см выше. Это как раз понятно и логично
                              +1
                              Вообще-то, приведённые примеры «правильно» расходятся с тем что помечено как «correct» в упомянутой статье. В частности, это касается пробелов между ключевыми словами if, while перед скобкой с условием.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Поддерживаю.
                                    0
                                    В исходной статье слитные скобки отнесены как wrong.
                                      –1
                                      zedalert, можете пожалуйста показать, где в моей статье используются слитные скобки? Я наверное очень невнимательный, и не заметил ошибку.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          Приношу свои извинения, я сначала не понял о чем речь. Спасибо. fixed.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Что меня всегда смущало во многих стандартах, так это правила именования констант, енумов и элементов енумов. Например, здесь это вообще не регламентировано.
                                        0
                                        Еще один положительный момент)).
                                        +1
                                        В Qt принято использовать отступы по 4 пробела. Но именно 4, и именно пробела.

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

                                            DizelGenerator, простите меня, но когда существует проект/фреймворк на десятки тысяч строк кода, лучше чтобы все было одинаково, нежели «как кому удобно». Так что я считаю этот постулат вполне логичным и очень даже правильным.

                                            Представьте ситуацию. Вы участник большого проекта на Qt. Работают над ним 15 человек. И каждый выравнивает «как кому удобно». Вы понимаете что произойдет с кодом?

                                            P.S. А вставлять «хабралинк на хабрачеловека» очень удобно — можно сразу призвать человека в тред и ждать ответа. Всем советую на ответы вставлять его.
                                              0
                                              Нет-нет, я только за стандарты кодирования! Не раз приходилось поддерживать чужой код, и пол беды, если бы там были свои, отличные от принятых, стандарты, но использовались везде, так обычно и этого нет. Я о том, что если отступы задаются символами табуляции (а не четырьмя пробелами), то кто-то хочет видеть большие отступы и настраивает свой редактор на отображение символа табуляции как 8 пробелов, другой — 4, может быть, 2. Но в коде-то отступы остаются символами табуляции.
                                            +1
                                            Да. Дааааа! ;) На самом деле почему пробелы вполне понятно — борьба с выравниваниями — отступы табами, а выравнивание пробелами. Иногда это бывает пропущено и всё оформление летит. Чтобы не бороться с этим проще постулировать 4 пробела.
                                              0
                                              Проще…
                                              Вот я не могу понять этого. Серьёзные мужи создают новые языки, пишут кроссплатформенный код, распараллеливают этот код. А запомнить, что отступы табами, а выравнивание пробелами — никак, лучше вообще табы запретить.
                                                0
                                                Вот именно. Голова занята полезными делами. Зачем отвлекаться на всякие мелочи? Код пишут не только профи, но и новички. И я чаще вижу, что с табами получается жуткая смесь. А с пробелами изначально этой проблемы нет. Минус только в том, что отступ зафиксирован — 4 пробела.
                                              +1
                                              этот вопрос больше религиозный, вым — «Нееет», а мне — «Да»
                                              +1
                                              Я как-то естественным путем пришел к такому же стилю написания кода и считаю его очень наглядным. Так что полностью поддерживаю Qt Coding Style, тем более учитывая, что Qt Framework — основной для меня
                                                0
                                                У меня та же самая ситуация. Правдо немного со звездочкой мучался в начале. Я писал ее раздельно и от имени переменной, и от типа.
                                                // Я делал так
                                                MyClass * obj = new MyClass( this );
                                                
                                                // А надо так
                                                MyClass *obj = new MyClass(this);
                                                
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    Да, меня тоже это всегда шокировало.
                                                      0
                                                      К счастью я так больше не делаю.
                                                0
                                                Постулат №3. Почему * или & должны липнуть к имени переменной?
                                                Постулат №4. Всегда считал что лучше ставить {} в любом случае, даже если одна строка после if или for. Помогает избежать ошибок при добавлении еще одной строки…
                                                  0
                                                  Опять-же. Когда есть большой проект, лучше чтобы все было одинаково. Представьте, что 15 человек в проекте, и все пишут по-разному. Это — каша. Гораздо лучше когда есть единый стиль.

                                                  А насчет {}, я с вами не согласен. Писать в любом случае — занимает в итоге много места.
                                                    0
                                                    Приношу извинения, не сообразил сначала.
                                                  0
                                                  То пробел есть то нет… это не хорошо…

                                                  // Правильно
                                                  if(foo) {
                                                  }

                                                  // Правильно
                                                  if (longExpression
                                                  + otherLongExpression
                                                  + otherOtherLongExpression) {
                                                  }

                                                  тоже самое с циклами

                                                  // Правильно

                                                  for (int i = 0; i < 10; ++i)
                                                  qDebug("%i", i);

                                                  // Правильно
                                                  while(a) {}

                                                  Смотрится неряшливо. Попробуйте настроить indent под ваши правила и тогда кода всегда будет смотрется однотипно, а не как сейчас…

                                                  Извините не удержался. :)
                                                    0
                                                    а… это просто автор-переводкик накосопорил с пробелами…

                                                    ээх… namespace как же так ведь тэг «Совершенный код» кагбы говорит нам…
                                                      0
                                                      Я пробежался поиском "){" и вручную просмотрел — вроде ошибок нету, пробелы стоят везде. Да и вы вставили примеры с пробелами. Можете указать на ошибку?
                                                        0
                                                        пробеги поиcком по по «if( » а потом поиском по «if(» в оригинале и ты наконец поймешь, о чем тебе все говорят ибо в оригинале таки «if (» а ты на этот пробел забил.
                                                          –1
                                                          А зачем он там нужен? оО
                                                            0
                                                            Чего минусуем-с? Мне неясно просто зачем вообще ставить пробел после if-а и перед скобками с условиями.
                                                              0
                                                              Вы когда просто предложение пишете на русском языке, перед скобками тоже пробел не ставите?
                                                                0
                                                                Когда я пишу на русском языке, я не использую фигурные скобки. Плохая аналогия.
                                                                  0
                                                                  причем ту фигурные скобки? Речь идет о круглых после «if»
                                                                    0
                                                                    Я также как (судя по всему) как и Evengard подумал что речь идет о "){" а не о «if(». Теперь все понятно, я исправил ошибки.
                                                                      0
                                                                      Нет, я подумал именно про «if(»
                                                                      Мне непонятно, зачем тут нужен пробел. Когда я пишу функцию, я же не пишу
                                                                      print («smth»);
                                                                      Я пишу
                                                                      print(«smth»);
                                                                      А всё потому, что аргумент относится к функции. Так же и с if-ом. Условие относится к if-у.
                                                                        0
                                                                        if — это не функция.
                                                                          0
                                                                          И? Это не объясняет, почему там должен быть пробел.
                                                            0
                                                            Приношу свои извинения, что-то до меня туго доходит… Сейчас поправлю.
                                                              0
                                                              awesome
                                                      0
                                                      Не согласен со следующими двумя пунктами:

                                                      > Для указателей и ссылок, всегда используйте один пробел между типом и ‘*’ или ‘&’, но никогда не ставьте пробел между ‘*’ или ‘&’ и названием переменной

                                                      Не согласен, поскольку * и & указывают на тип переменной, а не на имя.

                                                      > В этом постулате все предельно просто — главное не писать `virtual` перед названием переопределяемого метода в .h файле.

                                                      Категорически не согласен. Главное — ПИСАТЬ virtual! Жаль, что C++ не требует такого написания, как например Object Pascal.
                                                      Ну раз уж так, то надо самому хотя бы для себя писать virtual, чтобы всегда помнить, что это не твоя функция, а спущенная тебе сверху по иерархии классов.

                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                          0
                                                          1. Я тоже привык писать «type& var»/«type* var». Да и в том же стандарте встречаются обе формы записи. Но тем не менее, для большинства coding styles принят именно такой вариант.
                                                          2. Тут, скорее всего, как раз целью и было выделить новые виртуальные методы, которые есть в классе. А переопределённые можно пометить override по новому стандарту. (для старого можно просто define сделать, хотя это не будет так же полезно как в c++11)
                                                          0
                                                          if (address.isEmpty()) {
                                                          return false;
                                                          }

                                                          Вот так как-раз правильно. Скобки ставить нужно всегда.

                                                          Неправильно будет, когда у вас под if (в данном случае) появится какой-то макрос, а скобок нет.
                                                            +1
                                                            «Карниган & Ричи стайл»(с) — зло! :-)
                                                            Закрывающая скобка должна располагаться точно под открывающей. Открывающая скобка в конце строчки чревата своей незаметностью. Даешь каждой фигурной скобке отдельную строчку!

                                                            С основным тезисом («Скобки ставить нужно всегда») полностью согласен.
                                                              0
                                                              Согласен!
                                                              Правда иногда так лень ставить всегда скобки...))
                                                                0
                                                                Заведите уже себе нормальную IDE/Редактор с подсветкой блоков, скобок, виртуальных методов и тому подобного, люди 21 век на дворе, хватит кодить в блокноте.
                                                                  0
                                                                  Даже IDE не сможет сделать из вашего кода конфетку, если код написан кое-как. Аккуратность в кодировании повышает читабельность независимо от того, в IDE-ли или в блокноте.
                                                                    +1
                                                                    а никто не говорит про кое-как, речь идет про избыточность. Излишняя избыточность только затрудняет понимание кода. Приведу пример:
                                                                    Многие против постулата №8 и мотивируют это тем что virtual позволяет им отличать методы спущенные сверху от своих, но они например при таком подходе не смогут отличить собственные методы virtual (которые никуда не спущены) от методов спущенных сверху, однако —
                                                                    Используя постулат №8 и современную IDE (например Qt Creator) мы может отличить мы сможет отличить спущенные сверху переопределенные виртуальные метода (слова virtual нет, имя метода написано курсивом), от собственных виртуальных методов (слово virtual есть, имя метода написано курсивом) и от обычных методов тоже (слова virtual нет, имя метода написано нормальным шрифтом)

                                                                    Вообщем не надо искать удобства там где их нет.
                                                                  0
                                                                  all right-thinking people know that
                                                                  (a) K&R are _right_ and (b) K&R are right
                                                                  www.kernel.org/doc/Documentation/CodingStyle
                                                                  0
                                                                  Значит макрос неверный. Любой макрос, который состоит не из одного оператора надо заключать в do {… } while(0)

                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                Самое читаемое