Почти 30 лет назад в классической книге по шаблонам проектирования Design Patterns: Elements of Reusable Object-Oriented Software, авторы сформулировали один из самых известных, но недопонятых принципов в истории программирования:

Program to an interface, not an implementation.

— Erich Gamma et. al, Design Patterns: Elements of Reusable Object-Oriented Software

Зачем "программировать в интерфейсы"?

Термин «мертвый код» - это, скорее, жаргонное, чем научное название участков программы, на которые не может попасть управление и, таким образом, они никогда не выполняются. Разумеется, в нормальных программах таких участков быть не должно. Но поскольку языки программирования становятся все сложнее и сложнее (а программисты все тупее и тупее, шутка!) в кодах программ может быть все, что угодно.

Введение

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

Статья будет полезна разработчикам, которым пришло распоряжение написать документацию к ПО, а также авторам учебных пособий вузов. Я не питаю иллюзий, что ситуация как-то изменится что у первых, что у вторых, но помечтать всё же хочется.

Важно: пример из статьи не является вымыслом или шуткой!

Ещё важней: статья не является критикой математики, математику я люблю.

Я уже плакался по поводу исключения в x86-64 команд двоично-десятичной арифметики DAA/DAS и плакался по поводу отмены команды проверки целочисленного переполнения INTO. Теперь настала очередь плакаться по поводу выброшенной команды BOUND. Как говорится, леди и джентльмены, подставляйте свои жилетки и декольте. Начинаю плач.

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

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

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

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

1 - union - сумм тип из 70х, в С идея хранения одного типа из нескольких в одном участке памяти выглядит неплохо и сейчас, ведь там все типы это набор байт с заданным размером.

В С++ же использование union это автоматическое undefined behavior, например:

Если вы уже устали читать статьи о том, как применять модульное тестирование в новых приложениях, в то время как ваша жизнь в основном занята расширением и улучшением унаследованного кода – изложу вам план, который (наконец-то) поможет воспользоваться возможностями автоматизированного тестирования при работе с имеющимися приложениями. Это проще, чем кажется, особенно, если вы переложите на Visual Studio и JustMock всю тяжелую работу.

Люблю читать статьи о том, как приступить к автоматизированному модульному тестированию, потому что они полностью оторваны от реальности. Во всех таких статьях предполагается, что вы выстраиваете некое свежее приложение с чистого листа, но такого – будем честны – практически не бывает. Все мы знаем, что от 70% до 90% времени разработчика тратится на улучшение, расширение, модификацию и (иногда) исправление приложений, которые уже работают в продакшене. А я еще я добавлю, что никто не захочет вам платить за обвязку модульными тестами таких «уже существующих/унаследованных» приложений.

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

time.sleep(300)

Thread.sleep(300)

threadDelay 300

Довольно часто у студентов, изучающих C++ в определённых учебных кругах, складывается мировоззрение о том, что всё должно быть объектами. Попросите их написать программу, которая считает некоторое значение - и они начнут с создания объекта ValueComputer и метода vc.computeResult().

Например: дана задача с помощью динамического программирования посчитать количество способов замостить костяшками домино прямоугольник . Студент пишет:

Я уже упоминал, каким неприятным сюрпризом оказалось исключение команды INTO из системы команд x86-64, когда я переводил компилятор на эти команды. Давайте разберемся, нужна ли сейчас команда, которая отвечала за контроль целочисленного переполнения еще со времен процессора 8086.

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

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

Под катом старший разработчик ПО компании Google, Minhaz A V*, рассказывает об оптимизации производительности кода. Менее чем за час работы автор ускорил код на 18%, добавив в него всего пару строк. Несмотря на то, что в большинстве примеров этого материала используется C++, статья может быть полезна широкому кругу читателей.

*Обращаем ваше внимание: позиция автора не всегда может совпадать с мнением МойОфис.

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

Среди бесчисленных режимов адресации архитектуры х86 существует один такой…
Впрочем, почему «бесчисленных» режимов? Если разобраться, то их немного. Со времен первого процессора 8086 адресация укладывалась в байт, который имел аббревиатуру MODRM, где «MOD» - это собственно режим адресации (т.е. mode), «R» - регистр и «M» - очевидно, память (memory).
Если не рассматривать дальнейшее совершенствование системы адресации с помощью SIB-байта, то, поскольку под MODE в MODRM-байте выделено всего два бита, получается, что возможны всего-навсего четыре режима адресации.

Меня зовут Кирилл Мокевнин, я CEO и сооснователь онлайн-школы программирования Хекслет. Мы помогаем людям с самым разным бэкграундом стать разработчиками уже 10 лет. За это время я не раз замечал, что зачастую студенты плохо представляют себе профессию. Вещи, не относящиеся напрямую к технической составляющей программирования, но имеющие огромное значение для успеха в будущей специальности, становятся для них сюрпризами еще во время обучения.

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

Почему ты выбрал такой подход к решению?

• Не знаю. Прочитал в какой-то статье.
• Не знаю. Скопипастил его из X.
• Не знаю. Такой же подход я использовал в предыдущем проекте.
• Не знаю. Кто-то мне посоветовал.

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