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