Как почувствовать грязный код? Часть 2
#разработка
Для тех, кто пропустил первую часть. Спасибо подписчикам, которые поделились мнением о посте. Это приятно.
Итак, еще немного размышлений о том, что такое «грязный» код и как его избегать.
• непроинициализированные переменные. Подобные переменные могут нести в себе много проблем. Например, в цикле подобная переменная может вызвать падение при попытке взять из списка неверный элемент. К счастью, Android Studio подсвечивает подобные переменные, говоря о том, что они не были проициализированы. К этому же пункту относятся неиспользуемые переменные, которые остаются после рефакторинга. Они вызывают меньше проблем, однако захламляют код.
• большой список параметров. Подобные ошибки вызывают сложность в использовании функции. Особую сложность представляют собой функции, которые принимают параметры одинакового типа. Стоит только ошибиться в порядке передачи этих параметров и функция будет работать некорректно.
• огромное количество комментариев. Кажется, что комментарии помогают в использовании кода. Но некоторые разработчики увлекаются написанием комментариев и пишут их для очевидных функций. Стремитесь к тому, чтобы по названию функции можно было понять, что делает эта функция. Однако, не ленитесь писать комментарий, где используете «костыль» или делаете неочевидное действие. К этому же пункту отнесу автосгенерированные студией комментарии для классов и функций. Чаще всего они излишни.
• неиспользование раннего выхода. Иногда разработчики забывают о такой полезной вещи как ранний выход из функции. Если параметры или условия не удовлетворяют требования для продолжения работы функции, то ее можно тут же завершить при помощи
• злоупотребление наследованием. Наследование — полезные инструмент. Но когда цепочка наследников становится слишком большой, то это также ухудшает читаемость кода и приводит к проблемам и багам. Большинство подобных проблем лечатся при помощи делегирования.
Уверен, что есть еще огромное множество сигналов о «грязном» коде, но некоторыми из них поделился с вами. Применяйте эти знания для написания чистого кода.
#разработка
Для тех, кто пропустил первую часть. Спасибо подписчикам, которые поделились мнением о посте. Это приятно.
Итак, еще немного размышлений о том, что такое «грязный» код и как его избегать.
• непроинициализированные переменные. Подобные переменные могут нести в себе много проблем. Например, в цикле подобная переменная может вызвать падение при попытке взять из списка неверный элемент. К счастью, Android Studio подсвечивает подобные переменные, говоря о том, что они не были проициализированы. К этому же пункту относятся неиспользуемые переменные, которые остаются после рефакторинга. Они вызывают меньше проблем, однако захламляют код.
• большой список параметров. Подобные ошибки вызывают сложность в использовании функции. Особую сложность представляют собой функции, которые принимают параметры одинакового типа. Стоит только ошибиться в порядке передачи этих параметров и функция будет работать некорректно.
• огромное количество комментариев. Кажется, что комментарии помогают в использовании кода. Но некоторые разработчики увлекаются написанием комментариев и пишут их для очевидных функций. Стремитесь к тому, чтобы по названию функции можно было понять, что делает эта функция. Однако, не ленитесь писать комментарий, где используете «костыль» или делаете неочевидное действие. К этому же пункту отнесу автосгенерированные студией комментарии для классов и функций. Чаще всего они излишни.
• неиспользование раннего выхода. Иногда разработчики забывают о такой полезной вещи как ранний выход из функции. Если параметры или условия не удовлетворяют требования для продолжения работы функции, то ее можно тут же завершить при помощи
return. Если не делать это, то получаем большой набор вложенных операторов if else, который в будущем тяжело читать и понимать происходящее.• злоупотребление наследованием. Наследование — полезные инструмент. Но когда цепочка наследников становится слишком большой, то это также ухудшает читаемость кода и приводит к проблемам и багам. Большинство подобных проблем лечатся при помощи делегирования.
Уверен, что есть еще огромное множество сигналов о «грязном» коде, но некоторыми из них поделился с вами. Применяйте эти знания для написания чистого кода.