Поддерживаемый код 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. На всякий случай, сам я от своего стиля кодирования не страдаю, хотя он далек не только от совершенства, а даже просто... далек, короче.
Ответ на первый вопрос зависит от предпочтений каждого конкретного человека. Некоторые могут предпочесть более компактное и краткое решение, как в первом или втором примере, другие могут отдавать предпочтение более "простому" и понятному коду, как в вашем примере. Важно помнить, что чем проще и читаемее код, тем легче его поддерживать и изменять в будущем.
Ответ на второй вопрос - это вполне нормально иметь свой собственный стиль кодирования, сформированный за годы практики. Каждый разработчик имеет право на свой стиль и подход к написанию кода. Главное, чтобы код был понятен другим разработчикам, с которыми придется работать в будущем.
В вашем конкретном примере, ваше решение выглядит понятным и легким для восприятия. Оно может быть более длинным, но в то же время более читаемым для большинства разработчиков. Поэтому, если вам удобно писать в таком стиле и у вас нет проблем с его пониманием, то нет ничего плохого в том, что вы придерживаетесь своего собственного стиля кодирования.
Ответ на первый вопрос зависит от предпочтений каждого конкретного человека. Некоторые могут предпочесть более компактное и краткое решение, как в первом или втором примере, другие могут отдавать предпочтение более "простому" и понятному коду, как в вашем примере. Важно помнить, что чем проще и читаемее код, тем легче его поддерживать и изменять в будущем.
Ответ на второй вопрос - это вполне нормально иметь свой собственный стиль кодирования, сформированный за годы практики. Каждый разработчик имеет право на свой стиль и подход к написанию кода. Главное, чтобы код был понятен другим разработчикам, с которыми придется работать в будущем.
В вашем конкретном примере, ваше решение выглядит понятным и легким для восприятия. Оно может быть более длинным, но в то же время более читаемым для большинства разработчиков. Поэтому, если вам удобно писать в таком стиле и у вас нет проблем с его пониманием, то нет ничего плохого в том, что вы придерживаетесь своего собственного стиля кодирования.