Комментарии 44
Так себе идея.
Слегка условный, но типичный пример — читаем из внешнего источника строку, и пытаемся преобразовать ее в число. Как назвать отстутствие проверки и/или обработки ошибки в этом случае? Бизнес-требования изменились? Да как бы не так — это внешний источник, и доверять ему нельзя никогда.
Если конкретный человек склонен не учитывать в коде подобные факторы — то он это сделает еще раз, в другом месте. Даже если предпринять определенные усилия по предотвращению повторений — они все равно какое-то время обязательно будут. Если не предпринять — то будут с гарантией. Ошибки специфичны для человека. Для его опыта, характера и т.п.
Я не призываю при оценке кода отказываться от привязки к авторитетности источника, я призываю оценивать дополнительно в отдельном потоке без привязки к авторитетности.
Выверните свой вариант наизнанку: необходимая проверка отсутствует, но писал этот кусок очень опытный и матерый программист, которому вы доверяете на все сто, но задать вопрос в текущий момент ему нельзя по какой-то причине. Или наоборот: присутствует проверка, которая, на первый беглый взгляд, вроде-как не нужна. А писал ее "дилетант", уволенный давным давно.
В общем-то я имел в виду, что полностью это развязывать не стоит — потому что характерные типы ошибок специфичны для человека. И кстати, опытные и матерые тоже имеют тенденцию к тому, чтобы делать типовые для себя ошибки. Просто другие.
Ну то есть, в исходном предложении не хватает одного небольшого уточнения — с какой целью мы анализируем. Если мы хотим повысить качество — то найдя ошибку, сделанную конкретным человеком, обычно бывает полезно внимательно посмотреть на другой код, сделанный тем же человеком — скорее всего вы найдете там похожие подходы, фрагменты и т.п. Если же цели другие — то наверное да, иногда полезно отвлечься от персоналий вовсе.
необходимая проверка отсутствует, но писал этот кусок очень опытный и матерый программист, которому вы доверяете на все сто
Даже опытный и матерый программист может допустить глупую ошибку в силу многих причин. И здесь было бы вполне логично сделать именно такой вывод. Потому что, если по какой-то важной причине проверки здесь быть не должно, опытный и матерый программист оставит комментарий, почему проверки нет.
Даже опытный и матерый программист может допустить глупую ошибку в силу многих причин.
Потому что, если по какой-то важной причине проверки здесь быть не должно, опытный и матерый программист оставит комментарий, почему проверки нет.
Если программист под рассмотрением может допустить ошибку, то этой ошибкой вполне может быть пропуск комментария. Т.е. утверждать на 100% как оно должно было быть вы уже не можете.
Слегка условный, но типичный пример — читаем из внешнего источника строку, и пытаемся преобразовать ее в числоТакое вполне может быть, если профилирование показало, что чтение с проверкой корректности снижает пропускную способность сервиса на пару гигабит в секунду, поэтому проверки сознательно убрали.
К тому же, код основного цикла обработки мог слегка распухнуть из-за десятков тщательных проверок и перестать влезать в L1 Instruction Cache.
Дайте определение внешнего источника.
Хотя на мой взгляд стандартизация — это просто перераспределение страданий. Чем более стандартизирован код, тем больше степень страданий при написании, и меньше при чтении.
Оформление вообще не проблема, проблема это когда программист не стал утруждать себя чтением доков. Как может не раздражать, когда эндпойнт назван /api/user/createUser или все ответы, даже с ошибкой, имеют статус 200? Или когда код лежит архитектурно не в том месте? А зачем было открывать файл контроллера и писать там, если можно прямо в роутах оставить, ведь главное что работает и выполняет задачи бизнеса.
Знание и вера в то что в подобных ситуациях раздражение не принесет вам ничего полезного позволяет вспомнить эту статью и сознательным усилием переключить себя в иной режим. Глубокий вдох и глубокий выдох это еще один полезный биохак в таких ситуациях.
Некоторые люди умудряются записывать простые вещи очень замысловатым образом. Вот пример из головы, но похожий код я видел:
int someName(const int* a, int count)
{
int rv = 0;
const int* f = a;
if (f)
{
const int* t = f + count;
for(;f < t;)
{
if (!*(f++))
rv = 1, break;
}
}
return rv;
}
Как его не форматируй, проще код не станет, хотя то же самое можно записать куда более коротким и очевидным способом:
bool hasZero(const int* arr, int count) {
if (arr == nullptr)
return false;
for(int i = 0; i < count; ++i)
if (arr[i] == 0)
return true;
return false;
}
Функция или переменная плохо названа — ctrl+shift+R и в пару секунд она называется по хорошему. Табуляции вместо пробелов,… — ctrl+shift+F…! Комментарий избыточен или устарел — ctrl+D и его нет.О, отличные лайфхаки! А подскажите, с чем там надо Ctrl жать, когда есть файл на 6500 строк и там ряд функций, строк по 400 каждая, полученных путем копипасты друг из друга с небольшими изменениями, реализующими несколько различающуюся бизнес-так сказать-логику?
Где по 200 строк типа
x= asd_ewdfgh(hgfd_trew_zxcvb(zyx::asdf_iuyt(qwe_rtyu.begin(), qwe_rtyu.end()) + ytre_qwe(zyx::asdf_iuyt(qwe_rtyu.begin(), qwe_rtyu.end());
с разными названиями переменных, но одинаковым смыслом, который можно вынести в функцию x= do_work(qwe_rtyu);
.По итогу файл ужимается до 300 строк (обычной длины) и чуть проще становится для понимания, но занимает это жуть как много времени, вот бы хоткей какой знать…
А почему я должен испытывать какие-то эмоции? Это обычный контроль качества. Я спокойно описываю необходимые изменения, аргументирую, и тыкаю кнопочку request changes.
Если разработчик воспринимает сухую аргументированную критику кода как личное оскорбление — это его проблемы, не мои.
Ну это с их стороны чистый инфантилизм, скорее всего они ко всему этому относятся в этот момент как к оценкам в школе и ворчат на злобного учителя.
Что еще погано, даже если немного намекнуть человеку на это, то он в силу инфантилизма воспримет это как уязвление его самооценки.
И как бороться с этим, не очень понятно.
Пусть тогда и на компилятор обижаются, когда он warning-и выводит.
Детский сад, штаны на лямках.
Почему меня вообще должно волновать, старался человек или нет? Значение для бизнеса имеет только результат. Зарплату разработчик получает не за старания, а за выполненную с надлежащим качеством и в надлежащие сроки работу.
Другое дело, если бы я переходил на личности, типа "что за дерьмо ты написал" — я так, конечно, никогда не делаю. Если надо помочь — всегда по возможности помогаю, типа, давай расшарим экран и устроим сессию парного программирования. Главное, чтобы это привело к результату.
Стандарт PSR ратует за 4 пробела вместо табуляции, игнорируя очевидный факт: среда разработки большинства PHP-программистов изменилась с консольных редакторов на полноценные IDE, в которых оперировать табуляциями удобнее во многих смыслах: и удалять проще, нажимая Backspace один раз, и настроить можно индивидуальную длину табуляции по вкусу.
Во-первых, в любой нормальной IDE это прекрасно настраивается.
Во-вторых, Developers Who Use Spaces Make More Money Than Those Who Use Tabs :)
Ну и в-третьих:
- внутри команды разработчиков/группы единомышленников может быть какой угодно кодстайл (но зачем, если есть PSR-12?);
- один разработчик может использовать какой угодно кодстайл (но зачем, если есть PSR-12?);
- всё, что выкладывается публично, должно быть отформатировано по PSR-12, иначе лучей ненависти будет слишком много.
Ни одного разумного довода за пробелы я не слышал никогда.
Во-первых, в любой нормальной IDE это прекрасно настраивается.
Вы пропустили этот пункт?
Какой костыль? Вы шторм открывали хоть раз?
Хотелось бы всё-таки услышать хоть какие-то разумные аргументы за пробелы.
В любой нормальной IDE нет никакой разницы.
Лично для меня нет вообще никакой разницы. Главное, чтобы в проекте был code style и все его придерживались. Какой именно — по барабану. Но если есть общепринятый стандарт, всегда выгоднее его придерживаться: если понадобится форкнуть какую-то стороннюю библиотеку, с вероятностью 99% она оформлена в соответствии с общепринятым стандартом, и не понадобится ее реформатить, что упростит последующие мерджи с апстримом.
Если понадобится одолжить чужую клавиатуру, то с вероятностью 99% это будет QWERTY :]
Купить вам клавиатуру — это копейки, а регрессии из-за сложностей с мержем могут бизнесу обойтись в миллионы.
Если вы пишете опенсорс или свой собственный проект, то, конечно, дело ваше. А если вы получаете зарплату, то ее вам платят не за ваши личные хотелки, а за то, что нужно бизнесу. А стандартизация всегда бизнесу выгодна, любое нестандартное решение это всегда дополнительный cost of ownership. Любое нестандартное решение должно чем-то компенсировать этот рост TCO. Нестандартный code style не компенсирует это вообще никак, хоть убейся.
(И, да, если вы печатаете вслепую, то вам все равно, какие где буковки написаны, а если нет, то хоть какая там раскладка, все равно плохо. :-)
Тот же phpstorm штатно из коробки использует 4 пробела. При желании можно настроить на табы. Лень нажимать 4 раза бекспейс/delete? Есть Ctrl+Alt+L.
1. Некоторые редакторы вообще не способно нормально отображать табы.
2. При разных настройках отступов, съезжают блочные комментарии, сделанные табами (лол) справа от текста.
3. У кого-то код ревью с лимитом на длину строки не проходил из-за того, что у ревьюэра стояли более широкие табы.
Ну и Ctrl+Alt+L есть не везде, так что либо страдания в одну сторону, либо в другую.
Не судите чужой код строго