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

Эксперт
Статус
Оффлайн
Регистрация
29 Мар 2021
Сообщения
1,595
Реакции[?]
603
Поинты[?]
44K
тогда вопросов не имею, я ссылался чисто на формальные определения стандарта
мне тоже со стороны логики не даёт покоя словосочетание "константная переменная")
не совсем уверен что в английском языке есть слово получше "variable" для определения всей этой поебени, пойдёт
 
На самом деле я Zodiak
Участник
Статус
Оффлайн
Регистрация
22 Дек 2020
Сообщения
1,017
Реакции[?]
181
Поинты[?]
70K
не понял, что тут не так

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

под переменной я подразумеваю "data that is mutable".
да я просто опечалился тем фактом что необходимо еще один референс ставить, типа кроме как в хедере work, так еще и в исполняемом файле worker'а.
Но думаю если держать один инклуд который будет собирать в себе все референсы, и везде включаться, то все будет и чисто и правильно.
 
I Want to Die in New Orleans
Участник
Статус
Оффлайн
Регистрация
10 Окт 2020
Сообщения
514
Реакции[?]
495
Поинты[?]
84K
Но думаю если держать один инклуд который будет собирать в себе все референсы, и везде включаться, то все будет и чисто и правильно.
нарушение модульности + взлёт времени компиляции, ну и ещё пакет минусов в подарок, так лучше не делай
 
Тьомчик
Участник
Статус
Оффлайн
Регистрация
30 Июн 2020
Сообщения
727
Реакции[?]
150
Поинты[?]
58K
главное это понимать что пишешь, а на остальное похуй
 
Эксперт
Статус
Оффлайн
Регистрация
29 Мар 2021
Сообщения
1,595
Реакции[?]
603
Поинты[?]
44K
На самом деле я Zodiak
Участник
Статус
Оффлайн
Регистрация
22 Дек 2020
Сообщения
1,017
Реакции[?]
181
Поинты[?]
70K
нарушение модульности + взлёт времени компиляции, ну и ещё пакет минусов в подарок, так лучше не делай
да как тогда сук
вот такое это бля страшно.
1725233975057.png

Типа как бы чисто логически - он должен видеть переменную, порядок включения правильный
1725234073765.png
да зачем тебе ГЛОБАЛЬНЫЙ СТЕЙТ то нахуй

почитай про data locality я тя прошу умоляю бляяяять
блять я тебе уже говорил про использование переменной из меню - в хуках
 
Эксперт
Статус
Оффлайн
Регистрация
29 Мар 2021
Сообщения
1,595
Реакции[?]
603
Поинты[?]
44K
да как тогда сук
вот такое это бля страшно.
Посмотреть вложение 284700

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

блять я тебе уже говорил про использование переменной из меню - в хуках
variables.h:
#ifndef VARIABLES_H_
#define VARIABLES_H_

namespace var {

extern bool use_bebra;

} // namespace var

#endif
menu.cpp:
#include <project/menu/variables.h>

namespace var {
bool use_bebra = false;
}

void Menu::on_button_press(...) {
    if (var::use_bebra == true) { ... }
}
hooks.cpp:
#include <project/menu/variables.h>

void hook() {
    if (var::bebra == true) {
       bebra();
    }
}
 
На самом деле я Zodiak
Участник
Статус
Оффлайн
Регистрация
22 Дек 2020
Сообщения
1,017
Реакции[?]
181
Поинты[?]
70K
variables.h:
#ifndef VARIABLES_H_
#define VARIABLES_H_

namespace var {

extern bool use_bebra;

} // namespace var

#endif
menu.cpp:
#include <project/menu/variables.h>

namespace var {
bool use_bebra = false;
}

void Menu::on_button_press(...) {
    if (var::use_bebra == true) { ... }
}
hooks.cpp:
#include <project/menu/variables.h>

void hook() {
    if (var::bebra == true) {
       bebra();
    }
}
А ну, я примерно это и имел в виду, только обосрался.
Логично впринципе использовать это только там где необходимо, а не включать на весь проект, я что то очень сильно затупил.
 
Эксперт
Статус
Оффлайн
Регистрация
29 Мар 2021
Сообщения
1,595
Реакции[?]
603
Поинты[?]
44K
А ну, я примерно это и имел в виду, только обосрался.
Логично впринципе использовать это только там где необходимо, а не включать на весь проект, я что то очень сильно затупил.
чем меньше символов у тебя в скоупе - тем лучше

вот вам бля, ещё кусок clean code'а
 
get good, get zeus, for ever
Пользователь
Статус
Оффлайн
Регистрация
1 Июн 2018
Сообщения
558
Реакции[?]
90
Поинты[?]
37K
Назовите реальные правила и если есть возможность примеры, как должен строиться хороший, расширяемый проект, исходный код которого не стыдно обнародовать, удобно читать и расширять.
Только не надо в тупую сурс какого то готового 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
Следуя этим принципам и примерам, вы сможете создать проект, который будет легко поддерживать и расширять, а также будет выглядеть профессионально.
 
Сверху Снизу