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

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

static int ParseNumber(const char* tx)
{
  ....
  else if (strlen(tx) >= 4 && (strncmp(tx, "%eps", 4) == 0
    || strncmp(tx, "+%pi", 4) == 0 || strncmp(tx, "-%pi", 4) == 0
    || strncmp(tx, "+Inf", 4) == 0 || strncmp(tx, "-Inf", 4) == 0
    || strncmp(tx, "+Nan", 4) == 0 || strncmp(tx, "-Nan", 4) == 0
    || strncmp(tx, "%nan", 4) == 0 || strncmp(tx, "%inf", 4) == 0
          ))
  {
      return 4;
  }
  else if (strlen(tx) >= 3
    && (strncmp(tx, "+%e", 3) == 0
     || strncmp(tx, "-%e", 3) == 0
     || strncmp(tx, "%pi", 3) == 0   // <=
     || strncmp(tx, "Nan", 3) == 0
     || strncmp(tx, "Inf", 3) == 0
     || strncmp(tx, "%pi", 3) == 0)) // <=
  {
      return 3;
  }
  ....
}

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

— Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
— Да, этот язык называется brainfuck. Я знаю brainfuck.

И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?


Интерпретатор brainfuck, написанный на brainfuck

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

Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.

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

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

Code review может быть большой болью для команды, которая только начинает его внедрять. Вы в любом случае наступите на много граблей: будете проводить ревью дольше, чем пишете код, устраивать смертельные споры про расположение скобочек и разбираться, можно ли сливать ветку в master до аппрува команды или нет. Я собрал ряд практик, которые помогут вам сделать процесс адаптации чуть менее болезненным — по крайней мере, мне они точно помогли.
 
Этот материал — краткая выжимка моего опыта, накопленного за несколько лет работы в крупных командах мобильной разработки. Опыт по большей части в мобильной разработке, что оказало влияние на используемые примеры и ссылки. Для тех, кто предпочитает не читать, а смотреть, в течение пары месяцев должно появиться видео с конференции Mobius, где я рассказываю доклад на эту же тему, но с кучей подробных практических примеров.
 

JavaScript-разработчик из Франции, Себастьян Кастель, поделился мыслями о том, как на его взгляд должен выглядеть JavaScript код в 2017 году.

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



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

Только что я столкнулся с еще одним проявлением синдрома самозванца: «Я правда разработчик — или просто хорошо гуглю?»

Далее следовал ответ, в котором я, однако, не увидел главного — поэтому ответить придется мне: слишком уж многие боятся без каких-либо оснований.

Переведено в Alconost

Если информацию легко найти, это не делает человека глупым

Частенько мне доводится слышать одну историю — полагаю, подлинность ее сомнительна, но, как бы там ни было, суть такова. Когда у Эйнштейна попросили номер телефона, он полез его искать и сказал: «Зачем запоминать то, что можно найти менее чем за две минуты?»

Так зачем же мы пишем этот плохой код, который изо дня в день замедляет нашу работу?
Потому, что мы тогда вынуждены были сделать что-то быстрее!
Я оставлю вас наедине с это логической несостыковкой…
_{На одной из лекций Роберта Мартина}

У нас на DevConf будет не самый обычный мастер-класс. Там не будут рассказывать о новых технологиях или хайлоаде. Будут говорить о коде. Хорошем, плохом. Называется он Принципы хорошего кода на реальных примерах. Расспросим немного автора.

Кто ты и чем занимаешься?

Меня зовут Адель. Я фрилансер. Обычно занимаюсь backend-разработкой. Еще иногда пишу и дописываю плагины для PhpStorm. Из популярных Laravel plugin и .env files support.

Что тебя побудило на такой мастер-класс?

Удрученность текущей ситуации в отрасли. Все одержимы технологиями. В последнее время облачными. Читаешь вакансию, перечисляют используемые технологии, необходимый опыт (который почти никогда, на самом деле, не нужен). Очень круто звучит на собеседованиях. Приходишь на проект. Смотришь на код… и он печально говорит тебе: «Пристрели меня». Смотришь глубже и понимаешь всю его печаль. Он смертельно болен. Как раковые опухоли разрослись классы, которые кто-то, словно в шутку, назвал контроллерами. Как метастазы везде расползлись копипасты. На психологию кода давит то, что он лишь жалкая обвязка для крутых облачных технологий. Но пристрелить дорого.

Задача публикации: доступно изложить способ организации иерархии исключений и их обработки в приложении. Без привязки к фреймворкам и конкретной архитектуре. Описываемый способ является де-факто стандартом в сообществе: он используется во многих серьёзных библиотеках и фреймворках. В том числе Zend, Symfony. Не смотря на его логичность и универсальность, формального описания предлагаемого подхода на русском языке я не нашёл. После неоднократного устного изложения концепции коллегам, родилась мысль оформить её в виде публикации на Хабрахабр.

В языке PHP, начиная с 5-ой версии, доступен механизм исключений. В актуальной, 7-ой, версии этот механизм был улучшен и переработан с целью единнобразной обработки разных ошибок при помощи конструкции try{} catch...

В стандартной библиотеке (SPL) PHP предоставляет готовый набор базовых классов и интерфейсов для исключений. В 7-ой версии этот набор был расширен интерфейсом Throwable. Вот диаграмма всех имеющихся в версии 7 типов (изображение — ссылка):

Проверим на примере: пишем сервис с аэропортами и направлениями.

defmodule Airport do
  defstruct [:id, :name]
end

defmodule Direction do
  defstruct [:origin, :destination]

  def example do
    madrid = %Airport{id: "MAD", name: "Madrid"}
    riga = %Airport{id: "RIX", name: "Riga"}
    %Direction{origin: riga, destination: madrid}
  end
end

Пока что всё в порядке. Отлично, съели печеньку, смотрим, что дальше в джире. Список самых популярных направлений?

Я был недоверчив, когда прочитал это наблюдение у Реджинальда Брейтуэйт:

Как и у меня, у автора возникают проблемы с тем фактом, что 199 из 200 претендентов на каждое задание программирования не могут писать код вообще. Повторяю: они не могут писать никакого кода вообще.

Чтобы полностью раскрыть все преимущества Kotlin, пересмотрим некоторые подходы, которые мы используем в Java. Многие из них могут быть заменены на лучшие аналоги из Kotlin. Давайте посмотрим на то, как мы можем написать идиоматичный код на Kotlin.

Все началось лет 8 назад. Я тогда писал одну программу для математических расчетов, и мой преподаватель указал, что я неверно именую переменные. Он был прав: x, xx, xxx сложновато различить в коде. После переименования они превратились в redSegment, greenSegment, blueSegment (в контексте задачи именование было подходящее). Потом были «Рефакторинг» Фаулера, «Совершенный код» Макконнелла, «Паттерны проектирования» банды четырех… каждый день я погружался все глубже в бездну.

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

Введение

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

Хочу поделиться очень субъективными мыслями об изменении отношения к сложности за последние лет 50. Возможно, мои наблюдения касаются всей инженерии, но я поостерегусь и буду писать только про разработку ПО.

В последние годы мне стало казаться, что я упускаю что-то в методах разработки ПО. Весь мир радостно и с песней ускоряется, создаёт софт всё быстрее и быстрее, а я торможу. Чтобы не отставать, приходится преодолевать внутренний барьер неясной природы, действовать за границей которого выгодно но неприятно (мне). Не понятно почему выгодно. И не понятно почему неприятно.

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

Я же учился в основном по материалам, созданным в прошлом веке, «древним манускриптам», да ещё и научную фантастику читал классическую, поэтому невольно стал приверженцем «старой школы». В чем же разница?

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

Моя любимая особенность хорошего кода — это его скука. Предсказуемые выражения, одно за другим. Никаких сюрпризов, никаких трюков, никаких уникальных случаев. Никакого мета-программирования, конечно! Скучный код очень легко отлаживать, читать, объяснять.

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

Код, использующий неявное поведение, может быть основан на каком-нибудь недокументированном, но уже реализованном функционале. Например, в мире написана целая куча НЕВЕРНОГО кода, который полагается на то, что функция файловой системы, возвращающая список директорий, вернёт их в отсортированном по алфавиту порядке. Это и вправду часто работает именно так, но ровно до того момента, пока не ломается по «непонятным» причинам. А на самом деле просто никто никогда этой сортировки не гарантировал.

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

Информационная безопасность — это важно; впрочем, это знание мало кому помогает. Количество соединенных general-purpose компьютеров (==сложность) растёт каждый день, происходят очень реальные инциденты от Heart или Cloudbleed до Stuxnet или проблем с бортовым компьютером Toyota (когда машина не останавливается), и ситуация не становится лучше сама по себе. Становится хуже, потому что "интернет вещей" — это стартапы, делающие физическую инфраструктуру типа лампочек или дверных замков (разработчики SCADA плачут кровавыми слезами). Потому что огромное количество кода пишется на memory-unsafe языках. Потому что образование разработчиков — это, как правило, либо про фичи (проекты / этожпрототип), либо про фундаментальные алгоритмы (что не помогает пониманию того, что система работает не в вакууме).

Кажется, что основных корней проблемы два: это небезопасный инструментарий — например, ЯП (C/C++) и библиотеки (OpenSSL), и люди. Люди забывают про ИБ, думают "выпустим что-нибудь, а потом разберёмся", не понимают tradeoff'ы своих инструментов (то, что "C — это быстро", знают все, а вот про memory unsafety и масштаб UB — немногие), etc. Первая проблема сейчас решается сообществом: разрабатываются безопасные языки типа Rust и простые, понятные библиотеки типа TweetNaCl. Остаётся вторая (ведь хорошим инструментам надо ещё научить, как и соответствующему мышлению).

Поэтому мы проводим митап по информационной безопасности Security by Default.

Картинка из фильма «Размер имеет значение», 2009

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

Название частично позаимствовано из статьи Никлауса Вирта «Долой „жирные“ программы», которой в 2016г было ровно 10 лет, и актуальности она не утратила — а скорее вышла на новый уровень, кто не знаком — почитайте.

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

Языковой аспект
Аспекты памяти
Аспекты реального мира
Неязыковые факторы
Аспект человеческого фактора

Хабра, привет!

Не так давно у со мной произошел довольно-таки интересный инцидент, в котором был замешан один из преподавателей одного колледжа информатики.

Разговор о программировании под Linux медленно перешел к тому, что этот человек стал утверждать, что сложность системного программирования на самом деле сильно преувеличена. Что язык Си прост как спичка, собственно как и ядро Linux (с его слов).

У меня был с собой ноутбук с Linux, на котором присутствовал джентльменский набор утилит для разработки на языке Си (gcc, vim, make, valgrind, gdb). Я уже не помню, какую цель мы тогда перед собой поставили, но через пару минут мой оппонент оказался за этим ноутбуком, полностью готовый решать задачу.

И буквально на первых же строках он допустил серьезную ошибку при аллоцировании памяти под… строку.

char *str = (char *)malloc(sizeof(char) * strlen(buffer));

buffer — стековая переменная, в которую заносились данные с клавиатуры.

Я думаю, определенно найдутся люди, которые спросят: «Разве что-то тут может быть не так?».
Поверьте, может.

А что именно — читайте по катом.