C++ Cleancode в проекте (в частности софт)

[OXXXYMlRON]

тогда вопросов не имею, я ссылался чисто на формальные определения стандарта
мне тоже со стороны логики не даёт покоя словосочетание "константная переменная")

не совсем уверен что в английском языке есть слово получше "variable" для определения всей этой поебени, пойдёт

 

[honorbuddy]

не понял, что тут не так

инклуд гварды тебе не позволят вставить два раза референсы на апи work(er)?, данные живут в своих отдельных файлах, srp_test видит всё на свете..

под переменной я подразумеваю "data that is mutable".

да я просто опечалился тем фактом что необходимо еще один референс ставить, типа кроме как в хедере work, так еще и в исполняемом файле worker'а.
Но думаю если держать один инклуд который будет собирать в себе все референсы, и везде включаться, то все будет и чисто и правильно.

 

[annihilatorq]

Но думаю если держать один инклуд который будет собирать в себе все референсы, и везде включаться, то все будет и чисто и правильно.

нарушение модульности + взлёт времени компиляции, ну и ещё пакет минусов в подарок, так лучше не делай

 

[clearlyst]

главное это понимать что пишешь, а на остальное похуй

 

[OXXXYMlRON]

везде включаться, то все будет и чисто и правильно.

да зачем тебе ГЛОБАЛЬНЫЙ СТЕЙТ то нахуй

почитай про data locality я тя прошу умоляю бляяяять

 

[honorbuddy]

нарушение модульности + взлёт времени компиляции, ну и ещё пакет минусов в подарок, так лучше не делай

да как тогда сук
вот такое это бля страшно.

Типа как бы чисто логически - он должен видеть переменную, порядок включения правильный

да зачем тебе ГЛОБАЛЬНЫЙ СТЕЙТ то нахуй

почитай про data locality я тя прошу умоляю бляяяять

блять я тебе уже говорил про использование переменной из меню - в хуках

 

[OXXXYMlRON]

да как тогда сук
вот такое это бля страшно.
Посмотреть вложение 284700

Типа как бы чисто логически - он должен видеть переменную, порядок включения правильный
Посмотреть вложение 284701

блять я тебе уже говорил про использование переменной из меню - в хуках

#ifndef VARIABLES_H_
#define VARIABLES_H_

namespace var {

extern bool use_bebra;

} // namespace var

#endif

#include <project/menu/variables.h>

namespace var {
bool use_bebra = false;
}

void Menu::on_button_press(...) {
    if (var::use_bebra == true) { ... }
}

#include <project/menu/variables.h>

void hook() {
    if (var::bebra == true) {
       bebra();
    }
}

 

[honorbuddy]

#ifndef VARIABLES_H_
#define VARIABLES_H_

namespace var {

extern bool use_bebra;

} // namespace var

#endif

#include <project/menu/variables.h>

namespace var {
bool use_bebra = false;
}

void Menu::on_button_press(...) {
    if (var::use_bebra == true) { ... }
}

#include <project/menu/variables.h>

void hook() {
    if (var::bebra == true) {
       bebra();
    }
}

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

 

[OXXXYMlRON]

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

чем меньше символов у тебя в скоупе - тем лучше

вот вам бля, ещё кусок clean code'а

 

[Adofyn]

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

 

[Remario]

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

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

Создание хорошего, расширяемого и поддерживаемого проекта требует применения множества практик и подходов, которые способствуют чистоте кода, его удобочитаемости и упрощению процесса расширения и поддержки. Вот несколько ключевых принципов и техник, которые помогут вам организовать ваш проект:

1. Организация и структура проекта

• Модульность: Разделяйте код на логические модули и компоненты. Каждый модуль должен отвечать за определённый аспект функциональности. Например, можно разделить проект на модули обработки данных, интерфейса пользователя, логики и т.д.
• Чёткое разделение ответственности: Каждый класс или функция должны иметь чётко определённую ответственность (принцип единственной ответственности). Это облегчает понимание и тестирование кода.
• Структура каталогов: Используйте структурированную и логичную организацию каталогов. Например:

/src          # Исходный код
  /core       # Основные модули и классы
  /utils      # Утилиты и вспомогательные функции
  /network    # Модули сети
  /ui         # Интерфейс пользователя
/include      # Заголовочные файлы
/tests        # Тесты
/docs         # Документация

2. Качество кода

• Именование: Используйте осмысленные имена для переменных, функций и классов. Хорошие имена улучшают читаемость и понимание кода.
• Комментарии и документация: Документируйте код с помощью комментариев и документируйте публичные интерфейсы (функции, классы) с помощью специальных комментариев, таких как Doxygen. Это помогает другим разработчикам (и вам самим в будущем) понять, как работает код.
• Чистота кода: Следуйте стилю кодирования (например, используйте clang-format или другой кодировщик для поддержания единого стиля кода). Это упрощает чтение и поддержание кода.

3. Управление зависимостями

• Модули и библиотеки: Если проект растёт, рассмотрите использование внешних библиотек и фреймворков для решения общих задач, таких как обработка JSON, HTTP-запросов и т.д.
• Управление версиями: Используйте системы управления версиями (например, Git). Разделяйте функциональные изменения и исправления ошибок на разные ветки и используйте pull requests для интеграции изменений.

4. Глобальные переменные и состояния

• Избегайте глобальных переменных: Глобальные переменные могут привести к непредсказуемым побочным эффектам и затруднить отладку. Если необходимо использовать глобальное состояние, рассмотрите использование паттернов проектирования, таких как Singleton или Dependency Injection.
• Классы конфигурации: Если вам нужно хранить конфигурацию, создайте отдельные классы или структуры для этого и инстанцируйте их по мере необходимости.

5. Инклюды и заголовочные файлы

• Include guards: Используйте include guards (#ifndef, #define, #endif) в заголовочных файлах для предотвращения многократного включения одного и того же файла. Это помогает избежать проблем с компиляцией и увеличивает производительность компилятора.
• Прямое использование #include: Минимизируйте количество включаемых заголовочных файлов. Используйте forward declarations, когда это возможно, чтобы уменьшить зависимости между заголовочными файлами.

6. Тестирование и отладка

• Автоматическое тестирование: Пишите юнит-тесты для проверки функциональности. Используйте тестовые фреймворки, такие как Google Test или Catch2. Это помогает обнаружить ошибки на ранних этапах и обеспечивает проверку корректности кода.
• Инструменты отладки: Используйте отладчики и статические анализаторы кода для выявления проблем и улучшения качества кода.

7. Производительность и оптимизация

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

Пример
Предположим, вы создаете проект, который должен взаимодействовать с сетью и выполнять сложные вычисления. Вот как это можно структурировать:

• Проект:

/src
  /network
    NetworkManager.cpp
    NetworkManager.h
  /computation
    MathUtils.cpp
    MathUtils.h
  /ui
    MainWindow.cpp
    MainWindow.h
  main.cpp
/include
  /network
    NetworkManager.h
  /computation
    MathUtils.h
/tests
  NetworkManagerTests.cpp
  MathUtilsTests.cpp
/docs
  README.md

main.cpp:

#include "network/NetworkManager.h"
#include "computation/MathUtils.h"

int main() {
    NetworkManager network;
    MathUtils math;
    
    // Ваш код здесь
    
    return 0;
}

NetworkManager.h:

#ifndef NETWORK_MANAGER_H
#define NETWORK_MANAGER_H

class NetworkManager {
public:
    NetworkManager();
    void Connect();
    // Другие методы
private:
    // Приватные члены
};

#endif // NETWORK_MANAGER_H

MathUtils.h:

#ifndef MATH_UTILS_H
#define MATH_UTILS_H

class MathUtils {
public:
    static int Add(int a, int b);
    // Другие методы
};

#endif // MATH_UTILS_H

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