Статья посвящена довольно простым и очевидным советам по написанию чистого кода, однако не все так просто!
Написание чистого кода это непростая задача. Для достижения этой цели необходимо изучать множество различных практик и просматривать множество различных советов. И проблема заключается как раз в том, что подобной практики и советов настолько много, что вы просто перегружаетесь излишней, зачастую бесполезной, информацией. В результате, разработчику трудно принять решение какой практики или какому совету следовать. Давайте упростим поставленную задачу. В данной статье, вначале, мы обсудим выгоду написания чистого кода. Затем, мы рассмотрим шесть советов или практик, по написанию чистого кода, которые являются более популярными у разработчиков.
Советы по написанию чистого кода
Теперь, после того как мы обсудили некоторые выгодные аспекты написания чистого кода, пришло время изучить некоторые советы, которые помогут нам в его написании. Как мы можем видеть из следующих строк кода, чистый код охватывает и следует следующим советам. Эти советы – это то, что делает код более чистым, читаемым, понятным и простым. Нет необходимости реализовывать все советы. Реализация и дальнейшее следование одному или двум из них может быть достаточно, чтобы привести вас к положительному результату.
1. Пишите читабельный код
Всем известно, что код, который мы пишем, далее интерпретируется машинами. Но это не означает, что мы можем пренебрегать его читабельностью и ясностью. Всегда есть вероятность, что кто-то другой захочет работать с нашим кодом или ему придется с ним работать. Даже если мы пишем код, к которому никто не получит доступ, то мы сами можем вернуться к нему через какое-то время. По этой причине, в наших же интересах сразу писать чистый код, для того чтобы в любое время легко вернуться к работе с ним. Но как?
Самый простой способ – это использование пробелов. Сокращение кода перед его релизом является нормальным. Однако необязательно писать код, который имеет сокращенный вид. Вместо этого можно использовать различные опознавательные элементы такие, как: скобки, пустые строки и отступы для того, чтобы сделать структуру нашего кода более читабельной. Решение, использовать подобные элементы в структуре кода, значительно улучшит читабельность и ясность этого кода. Давайте просто взглянем на код для того чтобы все понять. Ниже приведены два простых примера:
Код:
// Плохой
const userData=[{userId: 1, userName: 'Anthony Johnson', memberSince: '08-01-2017', fluentIn: [ 'English', 'Greek', 'Russian']},{userId: 2, userName: 'Alice Stevens', memberSince: '02-11-2016', fluentIn: [ 'English', 'French', 'German']},{userId: 3, userName: 'Bradley Stark', memberSince: '29-08-2013', fluentIn: [ 'Czech', 'English', 'Polish']},{userId: 4, userName: 'Hirohiro Matumoto', memberSince: '08-05-2015', fluentIn: [ 'Chinese', 'English', 'German', 'Japanese']}];
// Лучше
const userData = [
{
userId: 1,
userName: 'Anthony Johnson',
memberSince: '08-01-2017',
fluentIn: [
'English',
'Greek',
'Russian'
]
}, {
userId: 2,
userName: 'Alice Stevens',
memberSince: '02-11-2016',
fluentIn: [
'English',
'French',
'German'
]
}, {
userId: 3,
userName: 'Bradley Stark',
memberSince: '29-08-2013',
fluentIn: [
'Czech',
'English',
'Polish'
]
}, {
userId: 4,
userName: 'Hirohiro Matumoto',
memberSince: '08-05-2015',
fluentIn: [
'Chinese',
'English',
'German',
'Japanese'
]
}
];
Код:
// Плохой
class CarouselLeftArrow extends Component{render(){return ( <a href="#" className="carousel__arrow carousel__arrow--left" onClick={this.props.onClick}> );}};
// Лучше
class CarouselLeftArrow extends Component {
render() {
return (
);
}
};
2. Используйте понятные слова для обозначения переменных, функций и методов
Давайте рассмотрим второй совет, который поможет нам в написании чистого и понятного кода. А суть совета заключается в использовании понятных слов при обозначении переменных, функций и методов. Но что означает «используйте понятные слова»? Понятные слова – это те слова, посмотрев на которые, не только мы, но и другие люди поймут, для чего предназначается та или иная переменная, функция или метод. Другими словами название само по себе должно говорить за переменную, функцию или метод.
Код:
// Плохой
const fnm = ‘Tom’;
const lnm = ‘Hanks’
const x = 31;
const l = lstnm.length;
const boo = false;
const curr = true;
const sfn = ‘Remember the name’;
const dbl = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((i) => {
return i * 2;
});
// Лучше
const firstName = ‘Tom’;
const lastName = ‘Hanks’
const age = 31;
const lastNameLength = lastName.length;
const isComplete = false;
const isCurrentlyActive = true;
const songFileName = ‘Remember the name’;
const yearsDoubled = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((year) => {
return year * 2;
});
В то же время какие-то вещи следует держать в голове. Использование понятных обозначений не означает, что мы должны использовать любое количество символов и слов при их создании. Хорошим универсальным правилом является использование трех или четырех слов максимум. Если у нас появляется необходимость в использовании больше чем четырех слов, то, возможно, мы пытаемся сделать несколько вещей за раз, и нам стоит сделать наш код проще. Итак, давайте использовать только необходимое количество символов для обозначения переменных, функций и методов.
3. Пишите код так, чтобы любая функция или метод выполняли только одну задачу
Когда я только начинал кодить, то я писал методы и функции, которые больше похожи были на швейцарский армейский нож. Мои методы могли содержать в себе и выполнять все что угодно. Одной из проблем было найти подходящее для такой функции название. Второй была проблема того, что никто, за исключением меня, не мог понять, что эта функция все-таки делает и как её использовать. Однако, иногда, даже я не мог разобрать, что я там написал. Поэтому мне приходилось писать инструкции к ним. Третьей проблемой было то, что эти функции были крайне непредсказуемыми. Я создавал очень запутанный код.
Затем, я уже не помню кто, мне дал этот прекрасный совет. Пиши код так, чтобы любая функция или метод выполняли только одну задачу. Этот совет изменил все и помог мне начать писать более «чистый» код. Начиная с этого момента, другие люди могли понять, что же творится в моем коде. Или им требовалось гораздо меньшее количество времени на это. Мои функции и методы также стали предсказуемы. Они стали постоянно выдавать одинаковый результат при одинаковом вводе. Кроме того, проблема с придумыванием названий для функций свелась к минимуму.
Если вы тратите огромное количество времени на придумывание названий для ваших функций и методов, или вам приходится писать длинные инструкции к своему кода для других людей, то, настоятельно рекомендую, рассмотреть и начать исполнять данный совет. Предоставьте возможность каждой функции или методу выполнять только одну задачу. Также используйте этот совет, если ваш код похож на швейцарский армейский нож. Поверьте мне, подобная универсальность ваших функций не является преимуществом. Это, скорее всего, недостаток, который может привести к негативным последствиям в любой момент.
Примечание: Совет по написанию функций или методов, каждая из которых выполняет только одну задачу – это есть принцип разделения обязанностей. Такая практика была представлена Робертом К. Мартином, в качестве одного из пяти принципов объектно-ориентированного проектирования, более известные, как SOLID. Если вы хотите узнать об этом больше, я рекомендую ознакомиться с данной статьей.
Код:
// Пример 1: Простое вычитание
function subtract(x, y) {
return x - y;
}
// Пример 2: Простое умножение
function multiply(x, y) {
return x * y;
}
// Пример 3: Двойные числа в массиве
function doubleArray(array) {
return array.map(number => number * 2)
}
4. Используйте комментарии в качестве пояснений
Неважно насколько серьезно вы подошли к вопросу обозначения переменных, функций и методов. Ваш код от этого все еще не настолько понятен и «чист» насколько это возможно. Код все еще содержит строчки, которые необходимо пояснить. Проблема может быть даже не в том, что их сложно понять или использовать. А как раз наоборот, проблема может заключаться в том, что будет абсолютно непонятно, а почему мы реализовали эту функцию или метод именно так, а почему здесь мы решили написать так. Смысл, идея, почему должно быть именно так остаются неясными.
Иногда нам придется прибегнуть к очень неординарным подходам решения той или иной проблемы, так как ничего больше не способно её решить или у нас просто нет времени на лучшее решение. И именно это довольно сложно объяснить с помощью только кода. Использование комментариев внутри нашего кода может помочь нам решить эту проблему. Комментарии могут помочь нам объяснить другим людям, зачем мы написали, то, что мы написали, и почему мы написали это именно так. В результате им не придется лишний раз гадать, а что же тут написано.
Что более важно, когда мы объясняем свои решения, то другие разработчики смогут предложить, возможно, лучшее решение проблемы, и тем самым улучшат наш код. Это возможно, так как они знают, в чем заключается проблема, и что необходимо получить в результате. Без этой информации им будет крайне сложно предложить лучшее решение. Или они даже пытаться не будут, так как подумают, что в этом нет нужды. Они подумают, что это в наших интересах, чтобы все оставалось, так как есть.
Итак, если мы вдруг захотим использовать какие-либо «костыли» или неординарные решения, то необходимо подобные решения оснащать комментариями, чтобы было понятно, почему мы сделали именно так. Лучше написать строчку или две строки комментария, чем заставлять людей гадать, а что же тут такое.
Однако имейте в виду, что мы подразумеваем написание комментариев, только там, где это необходимо. Не нужно комментировать плохой код. Написание комментариев к плохому коду – это замкнутый круг, который не поможет в его трансформации в «чистый» код. Если код написан плохо, то проблему нужно решать при помощи его улучшения, а не при помощи написания длинных инструкций к нему. «Чистый» код более предпочтителен, нежели инструкции к плохому коду.
5. Будьте последовательны
Когда мы ищем какие-либо особенные советы по кодингу или стили его написания, которые нам нравятся, то нам следует придерживаться найденного и стараться везде это использовать. Однако, использование различных советов или стилей в разных проектах, не всегда хорошая идея. Такой подход также полезен, как неиспользование вообще никаких советов или стилей. В таком случае возвращение к нашему старому коду не будет таким гладким и естественным, как это могло быть. Нам придется потратить некоторое количество времени на то, чтобы разобраться какой же стиль или совет мы использовали в данном проекте до того, как мы сможем начать с ним работу.
Наиболее выгодным в таком случае решением будет выбор нескольких советов и стилей, после чего необходимо просто придерживаться только их во всех ваших проектах. Вследствие чего, вам будет гораздо проще вернуться к старому коду для его доработок. Но что насчет экспериментирования? Пробовать различные советы – это хорошо. Такой подход может помочь найти лучшее решение для нашей задачи. И все-таки, лучше всего экспериментировать на отдельных экспериментальных проектах и задачах, а не с вашим основным проектом.
Кроме того, когда мы решаем немного поэкспериментировать, то мы должны проделать эксперимент несколько раз и на нескольких проектах. Необходимо потратить достаточное количество времени, что тщательно все проработать. Только когда мы полностью убедились, что нам нравится подобный совет или стиль, мы должны его реализовывать на реальных проектах. И когда мы решили, что пора это сделать, то лучше всего применить наши новые наработки во всех наших проектах. Безусловно, это займет время, но это заставит нас подумать обо всех изменениях правильно.
6. Регулярно проверяйте свой код
Это мой заключительный совет по написанию чистого кода. Просто писать чистый код – это еще не все. Наша задача не заканчивается точкой с запятой. Следующий шаг – это поддержание чистого кода в таком состоянии. Так скажем, «чистый» код требует обслуживания. После того, как вы что-то написали, то вы должны всегда это проверять, исправлять и стараться улучшить. Иначе, если мы не будем проверять наш код и не будем улучшать его, то со временем он просто устареет. Точно также, как и наши старые устройства. Если мы хотим, чтобы наш код всегда был «в форме», то мы должны регулярно обновлять его.
То же самое относится и к коду, который мы пишем ежедневно. Код в принципе имеет особенность со временем становится более громоздким и сложным, а не проще и понятнее. Однако, все зависит от нас, будет ли код сложным или он будет простым и понятным. Единственный способ достичь этого, это регулярно проверять, написанный нами код. Другими словами, нам нужно обслуживать его. Это может быть необязательно для проектов, о которых мы не заботимся или у которых нет будущего. Для всего остального, обслуживание — это часть вашей работы.
Заключительные мысли по написанию «чистого» кода
И вот мы в конце этой статьи. Данные шесть практик, которые мы обсудили сегодня, возможно, не те, которые имеют наибольшее влияние или самые значительные результаты. Тем не менее, они относятся к числу наиболее часто упоминаемых опытными разработчиками. Вот почему я выбрал именно их. Я надеюсь, что этих практик или советов будет достаточно для того, чтобы помочь вам начать писать «чистый» код. А теперь, как и с любым другим, необходимо только начать. Итак, рассмотрите хотя бы одну практику и попробуйте реализовать её.
Всем спасибо за ваше время. И до следующего раза, всем удачного дня!
Ссылка на оригинальную статью
Перевод: Александр Давыдов
Комментарии