Задать вопрос
Leo5878
@Leo5878
Улыбчивай, люблю учить и учиться

Как разделить код?

Пишу библиотеку на нативном es6 без зависимостей, нужно как-то разделить код на логические "модули".
Есть несколько функций которые работают с хешом, есть несколько функций, которые работают с событиями, раскидывают их по дому. Проблема в строктурированности такого кода. Сейчас написано строк 200 кода, а в нем уже начинаешь путаться, так как функции в перемешку идут, а не по порядку исполнения, а по порядку их выставить не реально, так как некоторые функции не зависимы друг от друга.
Например функции отвечающие за хеш и раскидывание событий по дому, не зависимы друг от друга. Но в конце они обращаються к одной функции.

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

И еще вопрос. Я считаю, что аргументы и все переменные, должны быть с каким-то префиксом вначале, чтобы было проще понимать, откуда приходят данные.
У меня переменная или аргумент может придти из другой функции внутри библиотеки, программистом передаваться, или, это вообще было взято у user'a, например hash. Внутри библиотеки, это нужно как-то разделить, чтобы понимать, откуда в функции, эти данные взялись.
Люди, которые писали собственные библиотеки, или что-то на подобии, опытные прораммисты, подскажите, как лучше писать, чтобы код в говно не превратился, которое даже ты сам не в состоянии прочесть!?
  • Вопрос задан
  • 908 просмотров
Подписаться 3 Средний 1 комментарий
Решения вопроса 1
@stratosmi
Сейчас написано строк 200 кода, а в нем уже начинаешь путаться, так как функции в перемешку идут, а не по порядку исполнения, а по порядку их выставить не реально, так как некоторые функции не зависимы друг от друга.


А и не надо по порядку.
Сгруппировать по смыслу, по функционалу. И дать внятные название, скажем, все обработчики начинать с On.


Я считаю, что аргументы и все переменные, должны быть с каким-то префиксом вначале, чтобы было проще понимать, откуда приходят данные.


Достаточно везде одинаковые по смыслу аргументы именовать одинаково. Но только на одном уровне абстракции. Пытаться использовать сквозное наименование - категорически не нужно.
Ну и локальные переменные можно выделять, например, префиксом l.

Прослеживать всю цепочку откуда приходят данные категорически не нужно.
Видеть в каком порядке исполняются функции категорические не нужно.


Это типичная ошибка новичка - все пытаться удержать в голове.
Для программиста нормой является "разделяй и властвуй" - абстрагирование на каждом уровне от предыдущего уровня.

Важнейший (ну или один из самых важнейших) навыков программиста - декомпозиция.


А вообще почитайте серию статью Дядюшки Бо "Чистая архитектура" и ее переложение под ваш язык программирования (есть несколько адаптаций статей под разные языки программирования).
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
Robur
@Robur
Знаю больше чем это необходимо
Нет никакой проблемы в разделении на файлы и каталоги и подключении этих файлов. Если вас это напрягает - вам нужен нормальный редактор/IDE с навигацией и научиться им пользоваться. Есть много способов структурировать код - разложить по файлам, самый простой. Можно так же сделать все в духе ООП если это имеет смысл.
Для пользователей вашей библиотеки нет разницы как она внутри устроена до тех пор пока все работает, им важно API которое вы предоставляете, вот его надо продумать хорошо. Никому не интересно какие там префиксы у переменных, и запоминать какой префикс что значит тоже никто кроме вас не будет.
Если хочется лучше все очень четко структурировать и понимать что откуда пришло и что из себя представляет - можно взять Typescript.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
22 дек. 2024, в 14:07
15000 руб./за проект
22 дек. 2024, в 13:01
50000 руб./за проект
22 дек. 2024, в 10:44
15000 руб./за проект