Совершенный код *

То, что написано ниже, для многих квалифицированных C++ разработчиков будет прекрасно известной и очевидной вещью, но тем не менее, я периодически встречаю using namespace std; в коде различных проектов, а недавно в нашумевшей статье про впечатления от высшего образования было упомянуто, что студентов так учат писать код в вузах, поэтому давайте повторим очевидное еще раз.

Итак... многие слышали, что using namespace std; в C++ считается плохой практикой. Касательно недопустимости использования using namespace в header-файлах вопросов обычно не возникает, если мы хоть немного понимаем, как работает препроцессор компилятора: .hpp-файлы при использовании директивы #include вставляются в код "как есть", и соответственно using автоматически распространится на все затронутые .hpp- и .cpp-файлы, если файл с ним был заинклюден хоть в одном звене цепочки (на одном из сайтов это метко обозвали как "заболевание, передающеемя половым путем"). Но вот про .cpp-файлы все не так очевидно, так что давайте еще раз разберем, что же именно здесь не так.

Держите ПЛК в режиме исполнения. Если ПЛК вышел из режима исполнения, то следует выдать предупреждение оператору.

Разбираем рекомендации по безопасному программироваю ПЛК, формируем список своих рекомендаций. Всех неравнодушных прошу под кат.

Разделите код на модули, рационально используйте программные организационные единицы. Тестируйте модули независимо.

Разбираем рекомендации по безопасному программироваю ПЛК, формируем список своих рекомендаций. Всех неравнодушных прошу под кат.

Современные мобильные приложения уже вполне серьезные Enterprise проекты, которые разрабатываются десятками, а то и сотнями разработчиков, содержат в себе множество тысяч строк кода и постоянно меняются и развиваются. Уследить за такой огромной кодовой базой помогает процесс автоматизации проверок кода и работы приложения. Сегодня расскажу о том какие инструменты вы можете использовать, чтобы улучшить стабильность вашего кода и не допускать ошибок, а также сэкономить время коллегам во время pull request.

Вы разрабатываете проект в маленькой команде, а то и вовсе один? Тогда эта статья вам ещё важнее, так как вы скорее всего не настраивали у себя такие проверки, а я расскажу почему это нужно сделать.

Что такое идеальный "квант информации" или "минимальная единица смысла" и зачем задаваться этим вопросом? С этим связано много боли, часто даже не осознаваемой. Мы предлагаем решение, но сначала нужно разобраться для чего это нужно. Рекомендуем ознакомиться с первой статьёй в серии.

Привет! Это вторая часть рассказа о том, как мы поддерживали язык Frege в IntelliJ IDEA. Первую часть читайте здесь. Сейчас мы поделимся, как сделали автодополнение, систему сборки, интерпретатор и систему типов. И как все это тестировали.

Расскажу о проделанном пути, чтобы найти идеальный, для моих целей, инструмент конфигурирования проекта и о создании легковесной библиотеки bestconfig, впитавшей в себя преимущества изложенных подходов.

В статье речь пойдет только о локальных способах хранения настроек, здесь не разбираются случаи загрузки из сети.

После создания проекта рано или поздно возникает вопрос: куда записывать номер версии, где хранить токены, пароли, настройки, каким форматом файлов конфигурации воспользоваться: .json, .yaml, .env, .cfg, .ini или просто создатьconfig.pyи записывать туда переменные?

Для каждого из перечисленных вариантов есть библиотека на python, приведу примеры самых популярных форматов

Привет! В этом посте мы расскажем, как реализовывали плагин для поддержки функционального языка Frege в IntelliJ IDEA. Если вам интересно, как IDE от JetBrains работают внутри, или вы хотите поконтрибьютить в языковые плагины (а может даже написать свой!), эта статья для вас. Мы пройдемся по этапам создания языкового плагина для IDEA, расскажем, с какими трудностями столкнулись, и как подружили этот язык с JVM-миром.

Так и тянет меня задать в заголовке статьи вопрос, что по здешним правилам не допускается. А ответ опять очевиден: регистр SPL вообще не нужен.

Я уже давно выступал с критикой системы команд AMD64, сейчас более известной как x86-64. Причем, задача специально анализировать появившиеся и исчезнувшие команды не стояла. Просто при переносе средств программирования с Win32 на Win64 возникал ряд проблем, вызывавших один и тот же вопрос: «почему же раньше все работало, а теперь нет?». Это касается некоторых выброшенных разработчиками архитектуры AMD64 команд, которые пришлось эмулировать, и, особенно, аппаратной поддержки контроля целочисленного переполнения с помощью инструкции INTO, которая вдруг стала недоступной.

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

Но все-таки проблемы как-то разрешились, и пришло время не только бороться с недостатками системы команд AMD64, но и воспользоваться ее достоинствами. А основных достоинств, по сравнению с IA-32, напомню, два: восьмибайтная адресация, снимающая предел в 4 Гбайт, и увеличенное число регистров общего назначения в два раза.

В случае регистров размером в 2, 4 или 8 байт действительно все логично и естественно. Можно даже сказать, что число регистров увеличилось более чем в два раза, поскольку указатель стека и не используется в вычислениях как остальные. Поэтому в IA-32 у программиста реально было 7 регистров общего назначения, а в AMD64 их стало 15, т.е. RAX, RBX, RCX, RDX, RBP, RSI, RDI и R8-R15.

Качеством кода в тестах часто пренебрегают. Когда в совместной разработке участвуют десятки QA-инженеров, возникает острая необходимость ввести формализованные правила, чтобы все могли быстро ориентироваться в тестовом проекте. К тому же часто тесты пишутся по аналогии или копируются с небольшими изменениями. Когда счет тестов идет на тысячи, то код, написанный в плохом стиле, быстро распространяется. Для решения этих проблем в тестовом проекте Wrike мы уже больше двух лет используем связку инструментов PMD и Checkstyle. И она отлично работает. В этой статье хотим поделиться опытом по настройке этих инструментов, их использованию и кастомизации.

Эта статья является переводом материала «Domain model isolation».

Термин «изоляция модели предметной области» уже давно используется, но его значение может быть не таким очевидным, как многие думают. В этом посте автор оригинала попытается описать, что значит правильно изолировать модель предметной области и почему это важно.

Вначале было слово, и было два байта, и ничего больше не было. Но отделил Бог ноль от единицы, и понял, что это хорошо.

Потом, опуская некоторые незначительные события мироздания, была вот эта статья от @novar.

Ну а еще некоторое время спустя вышел разбор задания из оригинальной статьи от @PsyHaSTe.

И обожемой, как этот разбор мне понравился. Серьезно, @PsyHaSTe, я теперь твой подписчик. Пиши еще, статья восхитительная, всем рекомендую.

Однако, покрутив немного сам код решения, я понял, что есть ряд моментов, которые я бы сделал иначе (так бывает, зачастую есть более одного способа решить задачу). В частности, меня зацепил вот этот кусок.

Всем привет, это PsyHaSTe и сегодня я хотел бы рассказать о том, куда меня занесла нелегкая в процессе оптимизации и рефакторинга кода решения тестового задания из статьи товарища novar (кто пропустил — рекомендую ознакомиться). Какие проблемы были у этого решения? Почему все-таки человеку отказали в работе? Что можно с этим сделать? Ответы на эти и многие другие вопросы оказались слишком длинными для комментария и вылились в статью с подробным разбором, примерами и альтернативной реализацией задания.

Если вам интересно кто в здравом уме мог для выполнения поставленной задачи написать код сочетающий монады с goto, а также одновременно сократил объем кода и увеличил его производительность, то добро пожаловать под кат. И, конечно же, самое вкусное, связанное с оптимизациями на базе работы JIT — в конце. Итоговую версию решения тестового можно посмотреть на гитхабе по ссылке.

Эта статья является переводом материала «Immutable architecture».

В этом посте автор оригинала хотел бы показать общий подход к внедрению иммутабельности в кодовую базу на архитектурном уровне.

Прежде всего, термин «Иммутабельность», применяемый к структуре данных, такой как класс, означает, что объекты этого класса не могут изменяться в течение их жизненного цикла. Существует несколько типов иммутабельности со своими нюансами, но это не являются для нас существенным. По большей части мы можем сказать, что класс является либо изменяемым, что означает, что его экземпляры могут изменяться тем или иным образом, либо иммутабельным (неизменяемым), что означает, что как только мы создадим экземпляр этого класса, мы не сможем изменить его позже.

Питон — простой, но мощный язык, который заслуженно стал одним из самых популярных. Тем не менее, иногда ему не хватает скорости статически типизированных языков с предварительной компиляцией, таких как Cи и Джава.

Если у вас есть задача выполнить трудоемкие вычисления, если нужно оптимизировать «подтормаживающее» приложение на Питоне без переписывания его на другом языке или если вы просто обожаете оптимизацию и хотите, чтобы код работал как можно быстрее, — тогда с большой вероятностью вы полюбите расширения на Си.

Расширения на Си — отличное дополнение в арсенале разработчика, будь вы фанат производительности и эффективности или любитель смешивать различные технологии и экспериментировать с чем-то новым: вы не только получаете почти «бесплатный» скачок производительности, но и расширяете функциональные возможности Питона.

Ревью кода это довольно обыденный процесс. Хотя и не многие могут объяснить, зачем это нужно команде — ревью будто без вопросов необходимо для мифического "хорошего кода". В целом сообразить пару причин, зачем же делать просматривать код коллег довольно просто, но такие причины далеко не всегда имеют весомое подтверждение. И далеко не всегда ревью достигает предполагаемых целей из-за недостаточного качества ревью и вовлечения команды.

Я расскажу про причину зачем вам лично может быть полезно ревью кода сокомандников.

Эта статья является переводом материала «What is functional programming?».

В этой статье Владимир Хориков попытается ответить на вопрос: что такое функциональное программирование?

Итак, что такое функциональное программирование? Этот термин возникает довольно часто, и каждый автор, пишущий о нем, дает собственное объяснение. На взгляд автора оригинала, самым простым и в то же время точным определением является следующее: функциональное программирование - это программирование с математическими функциями.

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