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

Давным-давно, когда мой отец вручил мне ключи от семейного VW Vanagon, чтобы 16-летний Бен, только что получивший лицензию, мог отвезти нас домой из церкви, я сразу же врезался в бордюр с такой силой, что у нас лопнуло переднее колесо. После, возможно, моей второй самой унизительной замены шин, мой отец все же заставил меня ехать до дома.

Это метафора лидерства или просто анекдот?

Вещи, которые имеют значение

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

Является ли стиль кода одним из таких важных вопросов? Недвусмысленно (и я ожидаю, что в этом хорошо построенном предложении будет много основных моментов): стиль кода имеет значение.

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

(Pssst - я уже говорил вам о моей самой неудобной замене шин?)

Шесть стильных причин

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

Руководства по стилю снимают когнитивную нагрузку, удаляя тривиальные решения. Когда программисты a-programmin '(а a-programmin' - это то, что они делают), им не нужно думать о том, куда идут члены класса, или вспоминать префиксы переменных, используемые в этом конкретном матерном файле . После того, как руководство по стилю усвоено, мозг каждого участника может предложить немного больше для других вещей, которые имеют значение. Назовем это кодовым эквивалентом наряда Стива Джобса.

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

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

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

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

Bonus Flamebait!

Это может привести к некоторым гневным комментариям (может быть, даже больше, чем к In-N-Out), но руководства по стилю для конкретной платформы важны. Конечно, C # отличается от Python. Я воспринимаю это как данность, хотя были предприняты некоторые (я считаю, ошибочные) попытки создать Единое руководство по стилю, чтобы управлять ими всеми. Я предлагаю более сильный аргумент: написание C # в Unity выглядит иначе, чем написание C # для сервера .NET Core ASP.NET. Это один и тот же язык, но очень разные платформы. JS в приложении React может выглядеть иначе, чем JS, запущенный на вашем сервере узла.

Дальнейшее чтение

Вам нужен гид по стилю? Может быть, вам просто нужен пример, и вы можете уйти и перестроить свой собственный. Вот несколько хороших ссылок: