Комментарии 14
Писать на Java )
+1
Да, сразу же про Java подумалось. И ее многословность часто подбешивает, как пример, реальное имя класса из недр Spring: HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor
Это конечно больше прикол, но вот такие имена SimpleBeanFactoryAwareAspectInstanceFactory встречаются часто. В случае с переменной получится совсем эпично (до появления var): имя длинного класса, потом имя переменной, которое генерится IDE по классу, и которое мало кто меняет, и наконец конструктор — тоже имя длинного класса. Смотрится это все сразу серьезно, энтерпрайзно. Но так уж сложилось, ничего не поделаешь.
Это конечно больше прикол, но вот такие имена SimpleBeanFactoryAwareAspectInstanceFactory встречаются часто. В случае с переменной получится совсем эпично (до появления var): имя длинного класса, потом имя переменной, которое генерится IDE по классу, и которое мало кто меняет, и наконец конструктор — тоже имя длинного класса. Смотрится это все сразу серьезно, энтерпрайзно. Но так уж сложилось, ничего не поделаешь.
0
Вместо обычного цикла while я выбрал цикл do… while.
Замена ошибочна, так как условие цикла в исходном варианте может оказаться ложным уже на первом проходе, если currentNode
является корнем либо не удовлетворяет условию condition
Тогда как второй вариант исполнит тело цикла как минимум один раз
0
Не зря говорят 'работает — не трогай'
Попытался сделать читабельнее метод из ~10 строк и даже при таком маленьком рефакторинге сломал что то
+3
Извиняюсь, невнимательно читал код.
В этом конкретном случае замена корректна, так как в первом варианте тело цикла совпадает по смыслу с кодом до цикла.
То есть было:
code; // какой то код
while(...)
{
code; // тот же код
}
Стало:
do
{
code;
}
while(...);
Тем самым убрали дублирование
+2
Если честно я закончил читать код сразу после «const traverseUpUntil = », зачем мне знать как оно сделано внутри, если по названию уже понятно, el и f для меня очевидны.
П.с. параметры на null никто и не проверил :)
П.с. параметры на null никто и не проверил :)
+1
Не говоря об ошибках, всю статью можно заменить на ссылку про самодокументируемый код
0
А чем 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 }
0
Это ведь просто пример на небольшом куске кода, который можно и нужно расширять на большие классы
0
Ну да, основная идея должна быть «действуйте по обстоятельствам». И надо уменьшать энтропию в коде, если у вас узел ноды обозначается el, то он во всем модуле или проекте должен так обозначаться, чтобы не было где-то el, где-то node, а где-то currentNode. И, естественно, копипасты во всех видах надо убирать, от синтаксических до логических. И контекст учитывать, parentNode переименовать в parent, например, а то масло масляное и многабукф
currentNode = currentNode.parentNode
vs
node = node.parent
+1
Я не понимаю смысла данных статей…
Вы прочитали книгу "Чистый код, Рефакторинг" и делитесь выжимками?
Честно когда вы вели видеоблог и обычный блог, было лучше...
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сделать код читабельным