Чем больше размер функции, тем больше вероятность того, что в ней есть вызовы других функций. Руководствуясь логикой недоверия ко внешнему коду, вызовы внешних функций нужно оборачивать в try/catch, а также тщательно проверить возвращаемый результат. Т.е. объем проверочного кода все-таки будет расти с увеличением размера кода функции.
Это тупиковый путь. В случае такой простой функции как isEven ваш подход может показаться логичным. Но уже код isEven вырос в 2 раза. Более сложный код вырастет еще больше. Усложняется поддержка кода.
В конце концов есть архитектура приложения, есть юнит-тесты. Гарантировать, что в функцию попадают корректные аргументы — можно и нужно.
Конечно, есть код, где проверки нужны обязательно, но везде их лепить — это неправильно на мой взгляд
Строка, которая может быть преобразована в число, будет обработана корректно. null, [], Infinity, -Infinity — для все этого проверка четности смысла не имеет. Обеспечивать какое-то спец. поведение смысла тоже нет. Правильнее обеспечить подачу корректных данных на вход функции.
Кстати, вариант с побитовым И выдает такие же результаты.
Минимальное взаимодействие — это немного не то. Используя тайпскрипт, для начала можно просто переименовать существующие файлы в ts, а затем потихоньку начать рефакторить код. На Dart'е придется сразу писать новый код.
Я серьезно еще в тайпскрипт не погружался. Пока меня привлекают 2 вещи: совместимость с JS-кодом и механизм интерфейсов как в Go. Класс автоматически считается реализующим какой-либо интерфейс, если у него есть нужные методы.
Сегодня вот наткнулся на библиотеку DefinitelyTyped, которая в перспективе сильно упрощает работу с существующим JS-кодом.
Оособенно радует, что множество ревнителей ООП имеют весьма смутное представление от тех же шаблонах проектирования. И сказать, чем отличается, например, Фабрика от Компоновщика не в состоянии. По большому счету основной недостаток объектной модели JS — это отсутствие механизма интерфейсов. В этом отношении очень хорошо смотрится Typescript.
Я сделал это :) Стратегия — по возможности не трогал нижнюю линию, накапливал отсортированную последовательность — 128, 256, 512, 1024. Ну а затем собрать еще 128 и склеить все вместе
Это всего лишь иллюстрация того факта, что правила раздельного и слитного написания «не» достаточно запутаны. К примеру, пункты 88.2 и 89.3 из therules.ru/hyphen-particles/
Я считаю, что четкой границы между этими правилами нет. Когда я пишу «немало» и «немного» я имею в виду «много» и «мало» без всякого противопоставления вроде «не мало, а много». Т.е. слитным написанием я подчеркиваю факт отсутствия такого противопоставления.
Скорее всего код будет выполняться в WIndows и компилироваться в Visual C++. А в этом случае RAND_MAX равен 0x7fff, т.е. из 32 бит DWORD'а «ксориться» будут только 15. По оставшимся старшим 17 битам вполне можно детектировать вирус
Конечно, же здесь нужен либо комментарий, либо отдельная функция. Но в большей части кода, например, веб- и бизнес-приложений без комментариев вполне можно обойтись. Я не верю, что большинству программистов каждый день приходится реализовывать какие-то нетривиальные алгоритмы.
P.S. Приведенная вами оптимизация имеет смысл далеко не на всех платформах. В частности, на x86 целочисленное умножение давно уже вычисляется за 3 такта, а в последних процессорах оптимизировано и деление.
В конце концов есть архитектура приложения, есть юнит-тесты. Гарантировать, что в функцию попадают корректные аргументы — можно и нужно.
Конечно, есть код, где проверки нужны обязательно, но везде их лепить — это неправильно на мой взгляд
Кстати, вариант с побитовым И выдает такие же результаты.
Сегодня вот наткнулся на библиотеку DefinitelyTyped, которая в перспективе сильно упрощает работу с существующим JS-кодом.
return arg % 2 == 0;
вместе с range based for
therules.ru/hyphen-particles/
Я считаю, что четкой границы между этими правилами нет. Когда я пишу «немало» и «немного» я имею в виду «много» и «мало» без всякого противопоставления вроде «не мало, а много». Т.е. слитным написанием я подчеркиваю факт отсутствия такого противопоставления.
P.S. Приведенная вами оптимизация имеет смысл далеко не на всех платформах. В частности, на x86 целочисленное умножение давно уже вычисляется за 3 такта, а в последних процессорах оптимизировано и деление.