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

На самом деле я Zodiak
Read Only
Read Only
Статус
Оффлайн
Регистрация
22 Дек 2020
Сообщения
1,095
Реакции
199
Назовите реальные правила и если есть возможность примеры, как должен строиться хороший, расширяемый проект, исходный код которого не стыдно обнародовать, удобно читать и расширять.
Только не надо в тупую сурс какого то готового sdk кидать, укажите на конкретные техники, я просто заебался лютейше срать в проекте, я понимаю что самое главное это функциональность и эффективность, но когда проект обростает, приходится просто рекодить и как бы блять колесо сансары даёт оборот.

Типа как лучше хранить глобалы с удобной доступностью, лучше использовать инклуд гварды или просто срать инлайнами и все в подобном роде.
 
Запомни одно правило, если работает не трожь.
 
1) Различные принципы ООП(SOLID, DRY и тд).
2) Почитай что делает инлайн и подумай, а лучшая ли это реализация?
3) Так же книжки в помощь, это к гуглу.
 
Мне вприцнипе сильно помогает правило single responsibility, то есть каждая функция отвечает за свое. А второе это тема про разбивку кода на функции, и если возможно то те функции еще на функции, в итоге получается как бы такие мини врапперы, но это очень сильно улучает читаймость кода. Чтобы не засирать глобал скоуп переменными, самый просто способ это просто их не делать, или ограничить к минимуму, и к примеру передавать сразу в функцию как аргумент. Если вообщем подытожить, то нужно создавать такой код, чтобы ты мог взять например config.cpp и config.hpp с проекта, вставить в полностью другой, и у тебя не было не одной ошибки при компиляции.
 
Назовите реальные правила и если есть возможность примеры, как должен строиться хороший, расширяемый проект, исходный код которого не стыдно обнародовать, удобно читать и расширять.
Только не надо в тупую сурс какого то готового sdk кидать, укажите на конкретные техники, я просто заебался лютейше срать в проекте, я понимаю что самое главное это функциональность и эффективность, но когда проект обростает, приходится просто рекодить и как бы блять колесо сансары даёт оборот.

Типа как лучше хранить глобалы с удобной доступностью, лучше использовать инклуд гварды или просто срать инлайнами и все в подобном роде.
много букав не осилил
 
1) Различные принципы ООП(SOLID, DRY и тд).
2) Почитай что делает инлайн и подумай, а лучшая ли это реализация?
3) Так же книжки в помощь, это к гуглу.
друг, я же не просто так сюда пишу, я конечно осознаю что форум заполонили зомби майнкрафтеры, но все же есть люди которые ПИШУТ код. А просто типа ну глянь те принципы глянь - те, это не то что я имел ввиду, я хочу узнать инфу из первых рук а не из книжки чела который дай бог один раз сдк наклинкодил
 
если работает не трожь
правило говна

data oriented >>> object oriented, и так было всегда

причём тут блядь клин код

---
а по теме:

код должен быть модульным.

используй генерики, забудь про ооп

уважай себя в будущем, не пиши говно которое тошно рефакторить - поищи паттерн, ебани кодген..

мне очень помог совет "не пытайся быть умным - пиши код так, будто у тебя айкью уровня комнатной температуры" - мой код автоматически стал в разы чище..
 
Последнее редактирование:
2) Почитай что делает инлайн и подумай, а лучшая ли это реализация?
больше вопросов чем ответов. как связан inline и "реализация" чего-либо? как это относится к архитектуре? (раз ты написал "почитай что делает ..." то ты явно подразумевал конкретно кейворд inline)


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

а инклуд гвард с инлайном не особо соприкасается, в любом случае при использовании переменных из одного заголовка в разных единицах трансляции тебе придётся использовать inline/extern

в целом порекомендовал бы почитать секцию SF в cppcoreguidelines, даст ответы на некоторые вопросы в посте
 
не вижу поинта не использовать инклуд гварды
не вижу поинта в успешной компиляции проекта с больше чем одним количеством .cpp файлов референсящих хедер

upd:
ну не увидел я "не", ебнутый, че поделать
использовании переменных из одного заголовка
переменные в заголовке не должны существовать от слова ваще
 
переменные в заголовке не должны существовать от слова ваще
А как тогда должны соприкасаться проверки? Условно у нас есть чекбокс, и есть хук, в хуке чек на переменную что сетается в чекбоксе.
Очевидно мы не хотим пихать меню туда где хуки и наоборот. Что делать в данном случае?

Или у нас есть разные модули визуалы/аимботы/мувмент. Везде используется база модуля, но мы не будем везде получать базу, это не логично, соответсвенно надо где то хранить глобальную переменную, с доступностью во всех модулях, и как поступать если не хранить переменную в каком то заголовке ?
 
надо где то хранить глобальную переменную
нихуя подобного, передаешь ее в параметре / референсишь локальную переменную

никакого блядь глобального стейта, забудь нахуй навсегда
 
переменные в заголовке не должны существовать от слова ваще
constexpr переменные в заголовках ведь всё ещё переменные, и объявление их в заголовках широко практикуется
 
constexpr переменные в заголовках ведь всё ещё переменные, и объявление их в заголовках широко практикуется
constexpr не переменные а константы, насколько мне известно

против констант я ниче не имею
 
нихуя подобного, передаешь ее в параметре / референсишь локальную переменную

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

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

переменная у тебя будет существовать локально - именно что через extern символ

декларацию на нее ты получишь из ХЕДЕРА - НО НИКАК не саму переменную..

переменная будет жить в своём счастливом cpp файле =)

inline bool bebra_in_use = false; заслуживает выбитых зубов

p.s.: никто не виноват что плюсы используют файл как translation unit, просто так устроен мир
 
constexpr не переменные а константы, насколько мне известно

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

1725231513060.png

таких квотов как "constexpr variable" в документе довольно много
 
Пожалуйста, авторизуйтесь для просмотра ссылки.

Посмотреть вложение 284697
таких квотов как "constexpr variable" в документе довольно много
6.1.6: A variable is introduced by the declaration of a reference other than a non-static data member or of an
object. The variable’s name, if any, denotes the reference or object.

Это именно что variable. Constant variable. Речь про мутабельность.
 
6.1.6: A variable is introduced by the declaration of a reference other than a non-static data member or of an
object. The variable’s name, if any, denotes the reference or object.

Это именно что variable. Constant variable. Речь про мутабельность.
да, и constexpr переменная попадает под это определение, потому что она всё ещё является объектом, имеющим особенность инициализироваться в компайл-тайме
Constant variable всё ещё считается variable, потому что стандарт цпп определяет переменные как объекты или ссылки, независимо от их мутабельности
 
Бля ну я не знаю, может я конечно тупоголовый или что то еще, но для доступа к переменной из одного модуля в другом, мне необходимо объявить ее и в хедер файле модуля в котором она определена, и в исполняемом файле где она необходима, хотя области видимости пересекаются.
Если это так и должно работать, то тебе не кажется что при крупном объеме переменных, это будет занимать очень много места)
Посмотреть вложение 284699

(Уточню что work включается раньше чем worker, так что область видимости как бы в порядке)
не понял, что тут не так

инклуд гварды тебе не позволят вставить два раза референсы на апи work(er)?, данные живут в своих отдельных файлах, srp_test видит всё на свете..
да, и constexpr переменная попадает под это определение, потому что она всё ещё является объектом, имеющим особенность инициализироваться в компайл-тайме
Constant variable всё ещё считается variable, потому что стандарт цпп определяет переменные как объекты или ссылки, независимо от их мутабельности
под переменной я подразумеваю "data that is mutable".
 
под переменной я подразумеваю "data that is mutable".
тогда вопросов не имею, я ссылался чисто на формальные определения стандарта
мне тоже со стороны логики не даёт покоя словосочетание "константная переменная")
 
Назад
Сверху Снизу