Comments 14
Писать на Java )
Да, сразу же про Java подумалось. И ее многословность часто подбешивает, как пример, реальное имя класса из недр Spring: HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor
Это конечно больше прикол, но вот такие имена SimpleBeanFactoryAwareAspectInstanceFactory встречаются часто. В случае с переменной получится совсем эпично (до появления var): имя длинного класса, потом имя переменной, которое генерится IDE по классу, и которое мало кто меняет, и наконец конструктор — тоже имя длинного класса. Смотрится это все сразу серьезно, энтерпрайзно. Но так уж сложилось, ничего не поделаешь.
Это конечно больше прикол, но вот такие имена SimpleBeanFactoryAwareAspectInstanceFactory встречаются часто. В случае с переменной получится совсем эпично (до появления var): имя длинного класса, потом имя переменной, которое генерится IDE по классу, и которое мало кто меняет, и наконец конструктор — тоже имя длинного класса. Смотрится это все сразу серьезно, энтерпрайзно. Но так уж сложилось, ничего не поделаешь.
Вместо обычного цикла while я выбрал цикл do… while.
Замена ошибочна, так как условие цикла в исходном варианте может оказаться ложным уже на первом проходе, если currentNode является корнем либо не удовлетворяет условию condition
Тогда как второй вариант исполнит тело цикла как минимум один раз
Не зря говорят 'работает — не трогай'
Попытался сделать читабельнее метод из ~10 строк и даже при таком маленьком рефакторинге сломал что то
Извиняюсь, невнимательно читал код.
В этом конкретном случае замена корректна, так как в первом варианте тело цикла совпадает по смыслу с кодом до цикла.
То есть было:
code; // какой то код
while(...)
{
code; // тот же код
}Стало:
do
{
code;
}
while(...);Тем самым убрали дублирование
Если честно я закончил читать код сразу после «const traverseUpUntil = », зачем мне знать как оно сделано внутри, если по названию уже понятно, el и f для меня очевидны.
П.с. параметры на null никто и не проверил :)
П.с. параметры на null никто и не проверил :)
Не говоря об ошибках, всю статью можно заменить на ссылку про самодокументируемый код
А чем condition отличается по сути от f?
f может быть принятым в данном контексте (модуле, проекте), обозначением унарного предиката, просто и понятно.
Точно так же с p, в функции из трех строк заменять его на currentNode, серьёзно? Другое дело если функция на 1-2 экрана, и там реально можно забыть что за p появляется в конце функции, ну или в функции больше 2-3 переменных с однобуквенными именами.
Интересно, какой вариант вам больше нравится:
f может быть принятым в данном контексте (модуле, проекте), обозначением унарного предиката, просто и понятно.
Точно так же с p, в функции из трех строк заменять его на currentNode, серьёзно? Другое дело если функция на 1-2 экрана, и там реально можно забыть что за p появляется в конце функции, ну или в функции больше 2-3 переменных с однобуквенными именами.
Интересно, какой вариант вам больше нравится:
int sum(int x, int y)
{ return x + y }
int calculateSum(int leftOperand, int rightOperand)
{ return leftOperand + rightOperand }
Это ведь просто пример на небольшом куске кода, который можно и нужно расширять на большие классы
Ну да, основная идея должна быть «действуйте по обстоятельствам». И надо уменьшать энтропию в коде, если у вас узел ноды обозначается el, то он во всем модуле или проекте должен так обозначаться, чтобы не было где-то el, где-то node, а где-то currentNode. И, естественно, копипасты во всех видах надо убирать, от синтаксических до логических. И контекст учитывать, parentNode переименовать в parent, например, а то масло масляное и многабукф
currentNode = currentNode.parentNode
vs
node = node.parent
Я не понимаю смысла данных статей…
Вы прочитали книгу "Чистый код, Рефакторинг" и делитесь выжимками?
Честно когда вы вели видеоблог и обычный блог, было лучше...
Sign up to leave a comment.
Как сделать код читабельным