Что такое золотое правило для разделения кода на функции?
Хорошо разбивать код на функции и классы для модульности / развязки, но если вы делаете это слишком много, вы получаете действительно фрагментированный код, который также не хорош.
Что такое золотое правило для разделения кода на функции?
6 ответов:
Это действительно зависит от размера и объема вашего проекта.
Я склонен разбивать вещи на функции каждый раз, когда что-то повторяется, и это повторение обобщается / абстрагируется, следуя золотому правилу сухой (не повторяйтесь ).
Что касается разделения классов, я склонен следовать мантре объектно-ориентированного программирования об отделении того, что является одинаковым, от того, что отличается, и разделять классы, если один класс является реализация более одной большой теоретической "идеи" или сущности.
Но честно говоря, если ваш код слишком фрагментирован и непрозрачен, вы должны попробовать рассмотреть возможность рефакторинга в другой подход/парадигму.
Вероятно, мое личное правило-это если оно длиннее 2 строк и на него ссылаются несколько раз на одной и той же странице (ASP.net), или несколько раз распространиться на пару страниц, чем я напишу функцию, чтобы это сделать.
Я думаю, что вы обычно должны думать о куске кода, который имеет шанс быть повторно использованным. Это приходит с опытом, чтобы понять это и планировать заранее.
Я согласен с ответами, которые концентрируются на повторяемости и исключении повторения, но я также считаю, что читаемость, по крайней мере, так же важна. Поэтому в дополнение к повторению я буду искать фрагменты кода (классы, функции, блоки и т. д.) которые делают больше, чем одну вещь.
Если имя, связанное с кодом, не описывает того, что он делает, то это хорошее время для рефакторинга этого кода на единицы, каждая из которых имеет единственную ответственность и описательное имя. Этот разделение забот поможет как повторному использованию, так и читабельности.Полезный код может оставаться в течение длительного времени, поэтому важно, чтобы вы (или в идеале кто-то другой) могли вернуться назад и легко понять код, который был написан месяцами или годами раньше.