4 приема работы, которые могут улучшить ваш код

Перевод статьи «4 practices for better code».

Как сделать свой код чище

«Чистый код всегда выглядит так, будто написан кем-то небезразличным».

Я помню свою первую работу в качестве разработчика. Это было вскоре после окончания курсов. Я попала в ситуацию, когда все разработчики предоставлены сами себе. Единственные ревью кода, которые у меня были, делались дизайнерами, проверявшими, соответствует ли мой код дизайну и ведет ли себя, как ожидалось.

Так продолжалось до тех пор, пока я – неизбежно – не застряла на одном из проектов. Один из старших разработчиков попытался отладить мой код и понял, насколько я еще джуниор. Чтобы помочь мне стать лучшим разработчиком и меньшей головной болью для него самого, позже он подошел ко мне, дал книгу и велел прочесть.

Это был «Чистый код» Роберта Сесила Мартина.

Могу честно сказать, что эта книга послужила причиной больших сдвигов в моем мыслительном процессе. Я стала иначе смотреть на код. В книге рассказывалось много всего. однако некоторые принципы я буду помнить, пока буду заниматься программированием. Четыре из них, перечисленные здесь, повлияли на меня больше всего и я думаю,что они наиболее важны для любого разработчика или инженера.

Тщательный подбор имен

Будьте внимательны, выбирая имена своим переменными и функциям, классам, файлам, да и вообще всему, что нуждается в имени. Имена должны описывать, что это за переменная и что делает эта функция. Это облегчает чтение кода и с первого прочтения делает очевидным, что выполняет данный код, избавляя тем самым от необходимости дополнительных исследований.

Плохо

[javascript]

const a = document.querySelector(‘.a’);
const b = document.querySelector(‘.b’);
const w = window.innerWidth / 2;
const h = window.innerHeight / 6 ;

b.addEventListener(‘mousemove’, (e) => {
const x = e.clientX / w;
const y = e.clientY / h;
a.style.transform = `translate3d(-${mouseX}%, -${mouseY}%, 0)`;
b.style.transform = `translate3d(${mouseX}%, ${mouseY}%, 0)`;
});

[/javascript]

Хорошо

[javascript]

const bg = document.querySelector(‘.background’);
const bgTop = document.querySelector(‘.background-top’);

const windowWidth = window.innerWidth / 2;
const windowHeight = window.innerHeight / 6 ;

bgTop.addEventListener(‘mousemove’, (e) => {
const mouseX = e.clientX / windowWidth;
const mouseY = e.clientY / windowHeight;

bg.style.transform = `translate3d(-${mouseX}%, -${mouseY}%, 0)`;
bgTop.style.transform = `translate3d(${mouseX}%, ${mouseY}%, 0)`;
});

[/javascript]

Имена должны быть по возможности короткими, описательными и написанными в одном формате во всей кодовой базе.

Плохо

[javascript]

function setTheValueOfSomethingAndReturnAValueToDoSomething() {

}
function addSomethingElseToThatThing() {

}

[/javascript]

Хорошо

[javascript]

const getTime = () => { … };
const getDate = () => { … };
const setNewDate = () => { … };
[/javascript]

Если в языке есть соглашение об именах, пользуйтесь им. В Javascript применяется camelCase, в Python используются символы подчеркивания, в других языках есть свои особенности.

Выбор имен в соответствии с общепринятыми правилами помогает как вам, так и вашим коллегам в работе с кодовой базой.

WET это плохо, а DRY — хорошо

Сухой и влажный код - принцип DRY

DRY* это один из лучших подходов к написанию кода. Если вы обнаруживаете, что ваше написание кода скорее WET, чем DRY, абстрагируйте его и сделайте свою жизнь проще, а код – короче (в разумных пределах).


*DRY: Don’t repeat yourself – «Не повторяйтесь». WET: Writing Everything Twice – «Написание всего дважды» или Wasting everyone’s time – «Лишняя трата времени для всех». В названии раздела используется игра слов: dry означает «сухой», а wet – «влажный».


Плохо

[javascript]

const goodPractices = {
dry: true,
wet: false,
kiss: true,
descriptive: true
}

const getDRY = () => goodPractices.dry;
const getWET = () => goodPractices.wet;
const getKISS = () => goodPractices.kiss;
const getDescriptive = () => goodPractices.descriptive;

[/javascript]

Хорошо

[javascript]

const goodPractices = {
dry: true,
wet: false,
kiss: true,
descriptive: true
}

const getParam = (param) => goodPractices[param];

[/javascript]

Принцип KISS

Этот твит излагает принцип KISS* лучше, чем смогла бы это сделать я:

Принцип KISS

«Когда жизнь дает тебе лимон, сделай виноградный сок, а затем сядь и позволь миру изумляться тому, как ты это сделал».

Ребята, никогда не делайте такого с кодом, который пишете! Придерживайтесь простоты. Давайте поможем таким образом человечеству!


*KISS: Keep it simple, stupid – «Сохраняй код простым, дурачок».


В целом, суть KISS в том, чтобы сделать ваш код более читабельным и простым. Добавляйте только то, что нужно, а не то, что выглядит интересно. Давайте сравним два решения для одного упражнения на программирование, которое я нашла на Code Wars.

Плохо

[javascript]

H=(Q,S)=>Q.map(V=>null==V||(V.map?H(V,S):’object’==typeof V?H(Object.values(V),S):/nu|st/.test(typeof V)&(V=+V)==V&&++S[S[0]+=V,1]))
averageEverything=(…Q)=>H(Q,Q=[0,0])&&Q[0]/Q[1]

[/javascript]

Хорошо

[javascript]

const plus = (v,w) => v+w ;
const length = a =>
typeof a==="number" ? Number.isNaN(a) ? 0 : 1 :
typeof a==="string" ? Number.isNaN(Number(a)) ? 0 : 1 : // or just `isNaN(a)`
typeof a==="object" ? Object.values( a || [] ).map(length).reduce(plus,0) :
0 ;
const sum = a =>
typeof a==="number" ? a || 0 :
typeof a==="string" ? Number(a) || 0 :
typeof a==="object" ? Object.values( a || [] ).map(sum).reduce(plus,0) :
0 ;
const averageEverything = (…a) => sum(a) / length(a) ;

[/javascript]

А теперь представьте, что в решении есть баг (поверьте мне, баги будут), и вам нужно его исправить. Если речь идет о первом примере, то с чего вы начнете? Конечно, выглядит он гениально и в нем всего три строчки, но какой ценой это достигнуто? Второй пример, в свою очередь, на 10 строк длиннее, но когда вы его читаете, вы понимаете, что происходит. Я не хочу сказать что ВСЕГДА нужно делать код длиннее, НО нужно стараться сделать его как можно более читабельным.

Длиннее не всегда значит лучше

…когда речь идет о функциях. Я не говорю, что функции должны быть маленькими вне зависимости от того, что функция делает. Но если функции длинные, обычно это означает, что они делают больше, чем следует.

«Функции должны что-то делать или отвечать на какой-то вопрос, но не обе эти вещи сразу».

В общем, если вы видите, что ваша функция выполняет какое-то действие, которое можно выделить и вынести в отдельную функцию, вам стоит это сделать. Помимо прочего это сильно упрощает тестирование.

Плохо

[javascript]

const submitHandler = e => {
e.preventDefault();
postApiData(‘/login’, {username, password})
.then(user => {
if (user && user.token) {
Cookies.set(‘token’, user.token)
}
return user;
});
if (!this.state.authError) {
this.props.history.push(‘/theories’)
}
}

[/javascript]

Хорошо

[javascript]

const redirect = (path) => this.props.history.push(path);
const login = (username, password) => {
return postApiData(‘/login’, {username, password})
.then(user => {
if (user && user.token) Cookies.set(‘token’, user.token);
});
}

const submitHandler = e => {
e.preventDefault();
login(username, password);
if (!this.state.authError) redirect(‘/somewhere’);
}

[/javascript]

Конечно, все это прекрасно, но не стоит относиться к этим подходам догматически. Думайте своей головой и применяйте эти принципы по возможности. Надеюсь, это поможет вам на вашем пути к лучшему коду!


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх