Вопрос стиля

[blood_shadow]

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

Вопрос - как лучше сделать запихнуть модель/делегат/представление в один
хедер или все-таки какими они маленькими не были заводить для каждого отдельный файл?

[alexman]

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

[blood_shadow]

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

наверно и я буду разделять, модель начинает стремительно расти 

[Пантер]

ИМХО, для каждого класса отдельный хедер.

[ieroglif]

для каждого класса веду отдельные h/cpp файлы, ничего не миксую, все enums выношу в отдельный enums.h и объявляю их внутри своего namespace. разбиваю все классы по неким смысловым группам, раскладываю их по папкам, в каждую папку свой pri файл
на каждую папку свой namespace
сейчас у меня около 70и файлов, организация такая:

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

    GUI - классы внешнего вида.
        пространство имён имеет интерфейсный класс GUI::IWidget, наследуемый от AUTH::AuthObject
        ..................................

    MVC - отдельное пространство для классов моделей и делегатов. классы отсюда тесно дружат с DB
        .............

    DB - работа с базами данных
        предоставляет методы
        ..................
        так как это один класс со статическими методами, то его файл лежит в MVC =)

    CORE - классы ядра. тут пока что не ясно что =) в будущем может замениться на SCRIPT

таким образом я нигде не путаюсь, знаю в каком неймспейсе у меня что лежит..
по необходимости создаю заголовочный файл с именем нейма, в котором у меня подключено то, что надо "во вне" (к примеру #include "auth/auth.h"
веду своё соглашение о наименовании классов, файлов, переменных
в итоге надо соблюдать некоторые правила, но код становится достаточно удобночитаемым и разбираемым даже когда разрастается, и даже сторонними программистами! =)
мало того, при таком подходе даже я сам легко разбираюсь в своём коде годичной-двухгодичной давности =))

[blood_shadow]

веду своё соглашение о наименовании классов, файлов, переменных

а можно насчет этого подробнее, особенно соглашение наименования классов и файлов интересует

[ieroglif]

веду своё соглашение о наименовании классов, файлов, переменных

а можно насчет этого подробнее, особенно соглашение наименования классов и файлов интересует

я для себя веду такое соглашение:

2. класс именуется конкретно своим функционалом, первая буква обязательно заглавная
    пример: Core, DBElements, ModelElements, Element

3. префиксы классов, если необходимы:
    I - класс интерфейс.
    DB - DataBase - класс базы данных
    M - модель для вьюшек. (обновлено с момента введения GUI::MVC, до этого Model)
    W - класс, имеющий виджет
    ID - ItemDelegate - класс для делегатов вьюшек

4. наименования функций:
    все функции за исключением конструктора и деструктора начинаются с маленькой буквы
    в функции, состоящей из нескольких слов кажое слово начинается с заглавной буквы
        пример: setColor() setMaximumSize()
    функции, что-либо передающие в класс начинаются с префикса set и имеют тип void
    функции, возвращающие какое-либо состояние класса начинаются с префикса get
    функции, обрабатывающие переменную по get/set называются так же как и переменная
        пример: int color; void setColor(); int getColor();

5. наименования переменных
    все переменные начинаются со строчной буквы.
    в переменной, состоящей из нескольких слов кажое слово начинается с заглавной буквы
        пример: dbElements (переменная для объекта класса DBElements)
    переменная, определяющая объект имеет такое же название, как и класс объекта (по возможности, конечно =))
    внешняя переменная, совпадающая по названию с внутренней начинается с "_"
        пример: void setInt(int _i) { i = _i; };
    любая переменная - private.
    если у переменной описаны set/get методы - она должна быть описана через Q_PROPERTY макрос

[Пантер]

  внешняя переменная, совпадающая по названию с внутренней начинается с "_"

Хреново. Так делать не рекомендуется.

[ieroglif]

  внешняя переменная, совпадающая по названию с внутренней начинается с "_"

Хреново. Так делать не рекомендуется.

как ты делаешь?

[Пантер]

Я использую подчеркивание в конце, т.е. someElement_. Начальное подчеркивание зарезервировано за макросами.

[Igors]

По поводу имен файлов. Как только проект разрастается, "слишком общие" имена файлов приходится менять. Примеры

Utils.h   // вероятно др. подзадача тоже потребует каких-то "утилей"
Matrix.h  // хорошие шансы что какая-то сторонняя либа тоже придет с Matrix.h

Лучше сразу зарядить "префикс" чтобы показать к какой подзадаче в проекте это относится, напр

UI_Utils.h
TR_Matrix.h

Ну и не надо слишком серьезно воспринимать рекомендации (мои - тоже). Руководствуйтесь здравым смыслом 

[Пантер]

ИМХО, файлы лучше в нижнем регистре именовать.

[blood_shadow]

    если у переменной описаны set/get методы - она должна быть описана через Q_PROPERTY макрос

[/quote]
а зачем это делать? это только для того чтобы свойства в дизайнере появились или по каким-то
еще другим соображениям?

[alexman]

    если у переменной описаны set/get методы - она должна быть описана через Q_PROPERTY макрос

а зачем это делать? это только для того чтобы свойства в дизайнере появились или по каким-то
еще другим соображениям?
[/quote]
Для QStateMachine, например.

[ieroglif]

Я использую подчеркивание в конце, т.е. someElement_. Начальное подчеркивание зарезервировано за макросами.

отличная идея =) перехожу на этот метод =)
+1 к именам файлов в нижнем регистре.
а на тему наименований типа UI_Utils - у меня бы это лежало в двух разных папках: UI и SCRIPTS (к примеру), эти классы бы были в разных неймспейсах UI::Utils и SCRIPTS::Utils соответсвенно, и, скорее всего, не предоставлялись бы пространством имён "во вне" ибо зачем внутренние утилиты группы классов выдавать другой группе классов? =)

Q_PROPERTY действительно постоянно использую для QStateMachine - на нём практически весь гуй пишется =) + подключаются иногда управления моделями. Что ещё забавно - возможность использования Q_PROPERTY макроса для "псевдо свойства" - у него есть только WRITE метод, зато этот метод вызовется когда гуй войдёт в какой-то определённый QState =) таким образом запускать какие-то фоновые задачи. к примеру, если программу перевели в QState XXX - запустить функцию обновления каких-то данных =)