Поддерживаемый код js: стоит ли писать «проще»? UPD. Я, наверно, плохо сформулировал вопрос. Всем ответившим спасибо. Речь идет не о стайлгайде, это все понятно, и над этим вопросом идет работа. Речь идет о подходе. Я не могу для примера выбрать сферическую фигню в вакууме. Я взял простой пример, в котором авторы применили подход, который (с моей т.зр) ухудшает поддерживаемость кода. Да, мой код написан иначе, в другой парадигме. Вопрос касался исключительно данного примера, в котором авторами использованы функции, возможно (!), соответствующие трендам, но усложняющие восприятие простого примера (опять же, возможно). Вопрос скорее был о том, стоит ли решать "просто" то, что решается просто, и не использовать что-то еще. Мамой клянусь, я по крайней мере пять функций для работы с массивами могу использовать для решения этой задачи. Только зачем?
Добрый день!
Вопрос скорее концептуально-педагогический к людям, работающим с чужим кодом. Натаскиваю пацана на интервью по js. В числе прочего решаем задачки с codewars. Там есть такая фишка - наверх всплывают варианты решения с большим количеством голосов за "лучшие практики". Мне они не нравятся, и вот почему.
Когда я работаю с чужим кодом (это в основном php), мне постоянно нужно тратить умственные усилия на понимание конструкции (иногда длинной) и удерживание в памяти что откуда взялось. Это быстро утомляет (на всякий случай, мой первый яызк - перл и я могу написать работающий однострочник, в котором через неделю не только я, но и десять бэтменов не разберутся). Поэтому сам пытаюсь писать пусть более длинный, но легче читаемый код.
Вот очень простой пример с codewars, чтобы не напрягать мозг. The first input array contains the correct answers to an exam, like ["a", "a", "b", "d"]. The second one is "answers" array and contains student's answers.
The two arrays are not empty and are the same length. Return the score for this array of answers, giving +4 for each correct answer, -1 for each incorrect answer, and +0 for each blank answer(empty string).
If the score {
if (e === "") {
return a;
}
if (e === array1[idx]) {
return a += 4;
}
return --a;
}
const score = array2.reduce(reducer, 0);
return score (x = y.reduce((s, e, i) => s + (e === x[i] ? 4 : e === '' ? 0 : -1), 0)) > 0 ? x : 0;
Мое скромное решение:function checkExam(array1, array2) {
if (array1.length !== array2.length)
return 'Error. Arrays have different lengths.';
let i, result = 0;
const length = array1.length;
const empty = 0, right = 4, wrong = -1;
for (i = 0; i < length; ++i) {
if (array2[i] === '') result += empty;
else if (array1[i] === array2[i]) result += right;
else result += wrong;
}
return (result < 0)
? 0
: result;
}
С моей т.зр мой несовершенный код проще для восприятия и исправления. При этом я понимаю и первое и второе решение, но трачу больше умственной энергии, которую можно было бы пустить на мирные цели.
Вопрос №1 к сведущим в js людям. Какое решение из трех вы бы предпочли, в качестве чужого кода для правок?
Вопрос №2. Может у меня просто привычка к определенному стилю, сформированная 20 лет назад, и я ее пытаюсь навязывать и порчу подрастающее поколение?
PS. На всякий случай, сам я от своего стиля кодирования не страдаю, хотя он далек не только от совершенства, а даже просто... далек, короче.

21 Авг 2019 в 06:22
335 +1
0
Ответы
1

Ответ на первый вопрос зависит от предпочтений каждого конкретного человека. Некоторые могут предпочесть более компактное и краткое решение, как в первом или втором примере, другие могут отдавать предпочтение более "простому" и понятному коду, как в вашем примере. Важно помнить, что чем проще и читаемее код, тем легче его поддерживать и изменять в будущем.

Ответ на второй вопрос - это вполне нормально иметь свой собственный стиль кодирования, сформированный за годы практики. Каждый разработчик имеет право на свой стиль и подход к написанию кода. Главное, чтобы код был понятен другим разработчикам, с которыми придется работать в будущем.

В вашем конкретном примере, ваше решение выглядит понятным и легким для восприятия. Оно может быть более длинным, но в то же время более читаемым для большинства разработчиков. Поэтому, если вам удобно писать в таком стиле и у вас нет проблем с его пониманием, то нет ничего плохого в том, что вы придерживаетесь своего собственного стиля кодирования.

20 Апр 2024 в 13:19
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Название заказа не должно быть пустым
Введите email
Бесплатные доработки
Гарантированные бесплатные доработки
Быстрое выполнение
Быстрое выполнение от 2 часов
Проверка работы
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Название заказа не должно быть пустым
Введите email
Доверьте свою работу экспертам
Разместите заказ
Наша система отправит ваш заказ на оценку 96 005 авторам
Первые отклики появятся уже в течение 10 минут
Прямой эфир