Comments 5
Ну если писать код через строчку, то он станет еще длиннее.
Зачем это делать? Что за стиль такой странный?
Если вам лично нравятся большие промежутки между строк – увеличьте в своем редакторе межстрочный интервал.
Я вот думаю, не написать ли мне статью. Уже года два как думаю. И даже вроде есть о чем. А тут нате - раз и статья. Целых полчаса поди писалась. А то, что слабая, не соответствует ожиданию (из названия) - это плохо. Я могу сказать, что код пахнет, если много переменных из одной буквы, если слишком длинныные строки, слишком мноо буков... Можно бесконнчно перечислять признаки чего угодно и ни слова не сказать о сути. Вот и ствтья ваша - слвчайный набор признаков без грамма истинной причины пояаления душка в коде. Извините, но статья ради статьи - не статья.
Ну вот по поводу списка параметров это прямо не рефакторинг, а вредительство. Было 5 явных параметров а стала структура с именем. То есть вместо того, чтобы просто прямо здесь посмотреть список параметров надо перейти в определение структуры и уже там посмотреть.
Обычно такое происходит, когда линтер говорит, что функция слишком длинная и человек просто делит ей на 2-3 куска. Внезапно оказывается, что было много локальных переменных, которые нужны во всех функциях, приходится делать по 5-7 параметров в функциях, он опять запускает линтер и линтер опять ругается. И так как человеку уже хочется побыстрее запушить он просто меняет 5-7 параметров на структуру MyFunctionParams. И в результате вместо одной функции в 100 строк мы получаем 3 функции по 80 строк и 2 структуры по 5-7 полей. Так себе рефакторинг, уж лучше длинная функция.
По-хорошему то надо сокращать количество параметров, но делать это другим способом глубоко проанализировать код и распутать там все использования переменных чтобы реально можно было свести к минимуму количество передаваемых сущностей/значений.
а есть всякие мерзкие библиотеки типа IMKL/AlgLib etc, где злые математики уже десятки лет не чураются в функции по десятку параметров передавать, и код у них там такой, что даже если ты его на зубок выучишь- то все равно невозможно понять, что он делает, не прочитав десяток специальных статей и пяток учебников. Так там за улучшение "запаха кода" можно знатно огрести- это как сыр с плесенью- он настолько воняет, что только истинные ценители могут понять, в чем там прелесть.
-- ALGLIB -- Copyright 25.09.2021 by Bochkanov Sergey *************************************************************************) procedure sparsesolvesymmetricgmres(const a: Tsparsematrix; const isupper: Boolean; const b: TVector; const k: TALGLIBInteger; const epsf: Double; const maxits: TALGLIBInteger; out x: TVector; out rep: Tsparsesolverreport; const _xparams: UInt64 = 0);
Двадцать лет люди кладут болт на вообще все принципы хорошего кода! КемелКейз? Информативные имена переменных? Самодокументируемый код? Да у нас функции по 200 строк- каждая третья! Правда, если я раскурил, как работает GMRES для решения разреженных симметричных систем (sparce symmetric matrix)- то код этой процедурки мне довольно понятен :-) и я понимаю, что или вот так- 200 строк и девять параметров, или лучше вообще никак, и любое предложение рефакторинга будет сразу же отклонено. А "глубокий анализ" этого кода показывает, что этот код- это просто код, который самым простым способом реализует сложный алгоритм. А алгоритм сложный просто потому что он сложный- ну вот так бывает. Причем, GMRES- это довольно простой алгоритм среди своего класса алгоритмов- там есть и понавороченнее- математики стараются :-).
Code smell: когда код плохо пахнет