Когда я должен повредить функцию?
Вы также можете добиться этого, используя UNPIVOT и PIVOT, как показано ниже.
;with cte1
as (select *,row_number() over(order by (select 1)) rn
from @table s
unpivot( [y]
for [x] IN (coli_day,coli_wee,coli_mon,coli_yea) ) u)
select coli_key,coli_day,coli_wee,coli_mon,coli_yea
from cte1
pivot(max(y)
for x in(coli_day,coli_wee,coli_mon,coli_yea)) pvt
Примечание: Измените @table на фактическое имя таблицы.
14 ответов
Я думаю, что необходимо пойти об этом от другого конца проблемы. Думайте вверх дном. Определите небольшие единицы работы, как можно меньше, и начните составлять свой код тот путь. Вы только столкнетесь с проблемами запутанного кода, когда Вы кодируете сверху вниз и не сохраните структурированный подход.
Если Вы уже имеете запутанный код и должны осуществить рефакторинг, в значительной степени необходимо запустить. Это - вероятно, больше работы для разбивания существующего запутанного кода, чем переписать его, и результат не может быть столь же хорошим.
Я не думаю, что должно быть твердое число для строк кода в методе также, но правильно написанный код не имеет методов больше чем с 5 - 10 строками на нижних уровнях и 20 - 30 строками в бизнес-логике. Дать Вам некоторую метрику.
Я не большой поклонник повреждения функции в несколько функций излишне. Это не надежная вещь - если существуют вещи, которые кажутся, что отличные логические единицы, затем любой ценой, выламывают их и думают о них отдельно. Но уберите не, только повреждают вещи ради некоторой инструкции как "одна страница за функцию" или "N строки на функцию".
Одно хорошее эмпирическое правило - то, что, если это не соответствует на одном экране, это стоит думать о разделении его. Но только если имеет смысл разделять его, некоторые долгие функции совершенно читаемы, и не имеет никакого смысла по-рабски разделять их на несколько функций только ради него.
Никогда не пишите функцию, которая при печати на перфорированной бумаге более высока, чем Вы.
Мне нравится эмпирическое правило, что необходимо вспыхнуть подфункция, если можно думать о хорошем названии, доменно-важном, его.
Когда кто-то может понять функцию верхнего уровня, обязательно не имея необходимость искать определение подфункции, Вы, вероятно, сделали чистую прибыль. (Но когда Вы ломаете его слишком далеко, Ваши имена начинают относиться к Вашим артефактам реализации, а не домену),
лично я повреждаю функцию, если она или сохраняет общие строки или общее время обработки.
если я только выполняю помощника однажды на главную функцию, я не беспокоюсь
Предел с точки зрения количества строк часто является непрактичным becuase, это не составляет удобочитаемость хорошо. Лучше попытаться разделить группы строк кода, которые имеют всего несколько исходных данных и всего несколько выводов и делают это отдельной функцией. Это не всегда возможно - затем часто мудро просто оставить код, как это а не осуществлять рефакторинг ради рефакторинга.
Я недавно обсуждал это с другом. Он предложил осуществить рефакторинг для разделения проблем, и я должен сказать, что должен согласиться. Таким образом, одна функция должна сделать одну вещь, если она делает больше чем одну вещь, разделите ее. В противном случае позвольте ему быть вместе, не имеет никакого смысла разделять функцию, только чтобы иметь его запутывают значение. В конце концов, функция является блоком кода, который делает одну вещь!
Хорошо, так как я кодирую в Python, таким образом, у меня есть свобода записать функции в функциях, в отличие от C, C++ или Java. Это, которое я чувствую, является лучшим выбором.
Если существует независимый код (в Ваших специфических особенностях случая для каждого типа сообщения), те области должны вспыхнуться.
Дело в том, что в принципале лучше специализировать функции. Но то, где каждый устанавливает предел, зависит очень от 1) "обычного" стиля программирования на определенных языках. (можно заметить, что, объектно-ориентированные языки склоняются к короче procedureds, чем скажем, C и т.п. 2), это зависит от Вашего способа запрограммировать. Каждый жесткий предел должен быть подвергнут сомнению. По моему скромному мнению. В целом там будет, вероятно, некоторое "естественное" распределение программ 3), я думаю, что нужно сохранить ум, то, что функция должна сделать, определенная задача берет, например, некоторую функцию для парсинга, это обычно намного длиннее, чем функция, просто устанавливающая некоторое поле в структуре. Или возвращение просто рассматривает, как может посмотреть цикл событий в Windows API. Так, чтобы все предположило, что могут быть серьезные основания для длинных методов...
Вопросы размера нет. Судите меня по моему размеру, делают Вас? - Yoda
Ваши основные проблемы являются удобочитаемостью, простотой и пригодностью для обслуживания. Хороший индикатор - то, если необходимо записать комментарии для объяснения раздела функции затем, что раздел является хорошим кандидатом на отдельную функцию.
Если Вы не записали это, и это уже работает: НИКОГДА!!! При разбивании его Вы, вероятно, повредите его, это настолько просто.
Если Вы пишете это, и Вы не уверены, на экранных яблоках правила, как сказали другие.
Существует много причин повредить долгую функцию в ее составляющие части. Самый важный:
- удобочитаемость
- пригодность для обслуживания
- ясность/намерение кода
Некоторые простые функции не могут быть повреждены в мелкие кусочки, негативно не влияя на перечисленные цели, таким образом, нет никакого твердого правила.