Качество кода *

• Отдавайте предпочтение полиморфизму, а не «if/else» и «switch»
• Код не должен знать о внутреннем устройстве объектов, с которыми он работает
• Функции должны быть маленькими
• Каждая функция должна выполнять одну задачу
• Принцип «DRY» — Don’t Repeat Yourself («не повторяйся»)

Речь пойдет о безымянных константах в программе, которые часто называют литералами. Если такой литерал нельзя использовать как непосредственный операнд в машинной команде, компилятору приходится выделять – а куда деваться! – этому литералу собственную память и далее оперировать адресом этой памяти.

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

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

В статье много практики. Сначала я покажу, как с помощью Decompose и Jetpack Compose создавать отдельные флоу приложения. Далее обсудим реализацию bottom-навигации. И, наконец, объединим несколько флоу воедино, чтоб получить навигацию по всему приложению.

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

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

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

Код-ревью сам по себе - не панацея. Его можно построить так, чтобы помочь проекту. Но эта польза не гарантирована - полно примеров, которым код-ревью идет во вред. Поговорим о том, где здесь скрываются подводные грабли и как провести код-ревью лучше.

В заметке Ричарда Тауэрса (Richard Towers) Typescripting the technical interview (есть перевод на Хабре: Руны и лёд: техническое собеседование по TypeScript) по ходу повествования была решена классическая задача расстановки 8 ферзей на шахматной доске. Для решения использовалась система типов TypeScript. Мне захотелось посмотреть, как эта задача будет выглядеть на Scala. Т.к. Scala 3 помимо развитой системы типов предлагает превосходную поддержку метапрограммирования, то здесь мы рассмотрим не только решение на типах, но и мета-программное решение.

«Почему сейчас программисты меньше говорят о паттернах проектирования? Какие паттерны (если они есть) все еще представляют ценность?»

Здравствуйте, меня зовут Дмитрий Карловский и я.. изобрёл $mol только для того, чтобы ваши глаза кровоточили, глядя в его код. Во всяком случае, такое ощущение может сложиться, если почитать разного рода околоJSНые чаты, но не обращаться к первоисточникам, где все технические решения вытекают из чисто прагматических рассуждений. Один из таких анализов позвольте представить вашему вниманию.

Привет, я backend-разработчик IT-компании SimbirSoft Леонид. В этой статье расскажу про 8 нюансов, которые я обнаружил при изучении шаблонов С++. Честно признаюсь, что наткнувшись на некоторые из них, я был удивлен: «Хм, SFINAE есть, а слова нет?» или «А что, есть разница между шаблоном в шаблоне и шаблоном с двумя параметрами?».

Материал будет полезен начинающим разработчикам, которые знакомятся с шаблонами, а также специалистам уровня middle, которые используют шаблоны время от времени.

Некоторые из примеров были описаны в cpp-referernce чуть ли не в самом первом абзаце, некоторые потребовали пошерстить stackoverflow, и в конце концов все есть в стандарте. Но кто учит язык по документации? У кого из нас не было такой ситуации: «Сейчас я код потыкаю, а там разберемся, что к чему». Так вот, сейчас пришло время узнать, как это работает и почему именно так. 

Я натолкнулся на этот мануал в интернете, когда гуглил описание "Верблюжьей вёрстки". Меня, технически и стилистически, очень продвинул данный текст, поэтому я взялся за его перевод, для себя. Переводчик я — так себе, моя основная цель — передать смысл текста в максимально полном объёме. Навык программиста и энтузиазм мне в помощь.

Текст написан от первого лица, и я решил сохранить этот момент. Поэтому "я" — это не я, а оригинальный автор статьи "Tao of Coding" — Коэн Уиттерс.

Читать далее

Данное руководство описывает стиль написания программного кода, который я разрабатывал несколько лет. Но стиль мой настолько неизвестен, что я не знаю никого, кто пользовался бы таким странным способом программировать, каким пользуюсь я. Тем не менее, он мне нравится и я бы хотел поделиться этим знанием (эй ты, везунчик, слышишь меня?). Этот стиль я использовал в разных языках: С, С++, Java, C#, Python,... .

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

Прошло уже лет 25 со дня изобретения концепции Model‑View‑Controller, а споры и её модификации не завершаются по сей день. Хотя очевидно, что в изначальном виде эта концепция ужасна, не объектно‑ориентирована и избыточна. А избыточно именно наличие контроллера, в то время как разделение визуализации и бизнес‑логики является сердцем этой концепции, из‑за чего и живет эта идея до сих пор. Но вопрос контроллера замыливается, хотя понятно, что на его месте должна быть реализация биндинга. Особенно, когда в игровом движке Unity это биндинг уже есть изначально, хотя и появился косвенно. Об этом подробно рассказываю в следующем видео.

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

Близится релиз языка NewLang с принципиальной новой «фишкой», переделанным вариантом препроцессора, который позволяет расширять синтаксиса языка для создания различных диалектов DSL за счет макросов.

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

О чем идет речь?

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

Условно, можно выделить два подхода к реализации DSL:

• Разработка независимых трансляторов синтаксиса с помощью генераторов лексеров и парсеров для определения грамматики целевого языка посредством БНФ и регулярных выражений (Lex, Yacc, ANTLR и т. д.) и последующей компиляцией полученной грамматики в машинный код.
• Разработка или встраивание диалекта DSL на языке (метаязыке) общего назначения, в том числе за счет применения различных библиотек или специальных парсеров / препроцессоров.

Далее речь пойдет о втором варианте, а именно, о реализации DSL на базе языков (метаязыков) общего назначения и новом варианте реализации макросов в NewLang как основы для разработки DSL.

Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём различные темы из компьютерной науки и без лишней зауми раскладываем их по полочкам.

В далёком 1988 году Бертран Мейер сформулировал свой принцип написания кода долгоживущих проектов под названием «Принцип открытости/закрытости» или OCP.

Вкратце, он звучит так: «программные сущности должны быть открыты для расширения, но закрыты для изменения». И, как любой короткий принцип, он требует десятки статей для толкования. Но к чёрту всю воду, включаем нашу соковыжималку!

Код Хабра день за днём впитывает в себя время, мысли и чаяния многих людей. Этому коду более 10 лет: он оброс множеством знаний, в том числе и тайных. Места c bus factor = 1 — не эка невидаль, а вполне конкретные люди с ответами на часто задаваемые вопросы.

Меня зовут Антон Каракулов, я тимлид команды бэкенд-разработки Хабра. Хабр стартовал в 2006 году, и за всё время здесь поработало, наверное, команд пять. Мне посчастливилось быть в двух из них, забегал в третью.

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

Все события утрированы, а совпадения — беспочвенны.

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

В eslint есть одно простое, но мощное правило, которое поможет вам в поддержании архитектуры приложения.