Lorem Ipsum: пишем от руки

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

Что помешало экипажу Crew Dragon выйти из корабля?

надели

Будущее математики?

отдельное спасибо за то, что совершенно нечитаемую презентацию перевели в хорошо структурированную статью, сделали преамбулу про xkcd, да и сам перевод по языку очень хорош

В играх детям нравятся атрибуты взрослой жизни: как мы разрабатывали обучающую игру для младших школьников

а можно как-то запросить доступ к бете? выглядит хорошо, хочется посмотреть в динамике, ну и детям показать конечно. жаль только, что addictiveness и большое количество времени за игрой считаются безусловным благом, пусть даже игра и образовательная.

Блокировка карт Payoneer Prepaid Mastercard® Card за пределами США

а вот и нет, я заморочился и через саппорт и много фоток документов поменял свой российский адрес в payoneer на тайский, отлично пользовался после 27го мая, а тут вот эта история прилетела

Чему нас может научить теорема о четырех красках в разработке ПО

упущен важный момент о степени детализации карты. Если ребра графа будут представлять собой дороги, а в качестве узлов будут города, все становится сложнее. Хорошие отправные точки на подумать в этом направлении: эта статья и книжка "Хаос. Создание новой науки"

Никогда не пишите длинных if-ов

это все сведется с бесконечным const isError = ....; if(isError) { .... }. Никакой дополнительной информации вы из этого не получите, условия просты как две копейки — зачем такой формализм?

Никогда не пишите длинных if-ов

согласен, но пост про code quality, а не про common sense :)

Никогда не пишите длинных if-ов

наверное так или так

Никогда не пишите длинных if-ов

вот в комментарии примерно попытался обозначить свой подход к первому листингу из статьи

Никогда не пишите длинных if-ов

если производительность не критична, то да, я тоже считаю, что как-то так и надо делать, все понятно. В противном случае можно оставить все как есть, но свести в итоге все к

  else if(isThreeCharsSpecialSymbol(tx))
  {
      return 3;
  }
  else if (isFourCharsSpecialSymbol(tx))
  {
      return 4;
  }

Или даже написать isNCharsSpecialSymbol(tx, n) и переделать все в цикл :)

Никогда не пишите длинных if-ов

у меня в изначальном варианте статьи был вариант рефакторинга из "ниче не понятно". но я не стал публиковать его по трем причинам:

1. Вы правы и опыта в плюсах у меня немного, последний раз писал активно на них лет восемь назад, а вникать заново в контекст не хотелось
2. У меня нет понимания big picture продукта и даже контекста этого метода
3. Я скорее не согласен с таким подходом к парсингу принципиально, и соглашусь с Dmitri-D, что в общем случае нужно использовать токены, но см п. 1 и особенно 2

Коллбэк в JS коде в данном случае совсем не страшен, это синхронная функция, фильтрующая уже имеющийся массив с небольшим числом элементов.

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

Никогда не пишите длинных if-ов

блин, не увидел, что с кодом случилось

else { 
   let firstConditionIsTrue = longCalculatedBoolean(); 
   let hasSecondCondition = secondCondition != null;
   if (firstConditionIsTrue && hasSecondCondition ) {
 .    ... 
   }
}

Никогда не пишите длинных if-ов

в данном случае да, ничем не лучше, но не все пользуют C# или что-то еще где есть оператор ?. Валидность, о которой вы пишете, должна проверяться внутри модели, валидность в данном контексте выполнения, как мне кажется, допустимо оформлять так.

Никогда не пишите длинных if-ов

ну это просто мое понимание того, как должно выглядеть название поста, в который хочется зайти и написать комментарий, так-то я пишу, что все не так однозначно конечно :)

Никогда не пишите длинных if-ов

да, это другие люди. Для меня блог pvs-studio является естественным источником кода с багами из-за дефицита code quality для статьи на Хабре. Если подскажете лучше — будет интересно взглянуть. Хотя если за эту статью мне предложат денег (бывает такое, что предлагают денег за статью постфактум?), не откажусь, честное слово :)

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

Вообще, если фанатично следовать этому правилу (хотя я сам так не делаю конечно), всегда можно переписать else if как
else { let firstConditionIsTrue = longCalculatedBoolean(); let hasSecondCondition = secondCondition != null; if (firstConditionIsTrue && hasSecondCondition ) { .... } }
возможно это и правда будет читабельней в каких-то случаях

Никогда не пишите длинных if-ов

я бегло прошелся по Макконнеллу перед написанием статьи (блин, три сдвоенных согласных это круто) он, безусловно, пишет про самодокументирующийся код, смысловые названия переменных и все такое, но на условиях он не делает какого-то отдельного акцента на условиях.

Проблема в том, что большинство тех, кто более или менее следуют макконнелловским принципам, на условиях сразу сползают на уровень кода в районе уроков по информатике в девятом классе. Но это субъективный опыт конечно.

Никогда не пишите длинных if-ов

спасибо, все это верно. Я просто старался примеры подобрать с использованием самых простых инструментов. Сам активно использую и C#, и JS, поэтому активно пользуюсь всеми упомянутыми вами инструментами. И user.IsValid() имеет такую же ценность как userExistsAndValid в плане code quality, особенно если у вас одно и то же понятие IsValid в десяти разных местах кода. А вот если это выливается в повсеместные if (user.IsValid() && user.lastName..., то, возможно, каждый раз стоит иметь перед глазами всю цепочку логических операций.

Я тут не пришел к вам со светочем абсолютной истины, просто вот придумал делать так, понравилось, выразил в словах и написал на Хабр :) Не думаю, что может быть какой-то однозначно "лучший" подход вообще

Никогда не пишите длинных if-ов

ну это же просто underscore helper, его можно было бы легко заменить на [].some(), просто я оставил все как было, кроме того, что непосредственно к статье не относится. Ну а массив this.serviceAccounts, как может быть можно догадаться из контекста, редко бывает больше 10 элементов.

Исключительная роль босса

такая работа, судя по всему, скоро окажется на грани вымирания в развитых странах