[Перевод] История об ужасах стандартов кодирования
Мы тогда писали под DEC VAX на VAX Basic. Чтобы вся эта история имела какой-то смысл, вы должны понимать, что VAX Basic не был тем классическим Basic, о котором вы думаете. Разработчики компилятора из DEC начали с синтаксиса Basic и понемногу добавили всё хорошее из FORTRAN, Modula II и Pascal. Например, ещё в начале 1980-ых в языке уже были исключения.
Также нужно помнить, что в 1980-ых ещё не существовало полноценных IDE с богатыми редакторами кода (вроде Visual Studio). Мы использовали нечто, называемое TPU (Text Processing Utility). Эта программа была несколько мощнее, чем Notepad, но значительно уступала современным редакторам. Тогда она соревновалась с Emacs и vi. В результате, каждый разработчик был сам ответственен за свой стиль кода, а текстовый редактор в это дело совершенно не вмешивался.
Марк определил строгий набор правил и стандартов написания кода. Его приверженность этим стандартам была близка к фанатизму. К примеру, он мог приконнектиться к рабочему компьютеру ночью из дому (а в тот момент это означало использование модема со скоростью около 1200 бод) ради ревью кода. На следующее утро меня ждало совещание с Марком, где он построчно комментировал мой код, указывая на ошибки в стиле и требуя, чтобы я сегодня же их исправил.
Некоторые правила выглядели для меня абсурдными. Например, он требовал, чтобы каждая строка начиналась с табуляции и двух пробелов. Вы только вдумайтесь — и табуляции, и двух пробелов! Почему двух? Я до сих пор этого не знаю, но это был наш стандарт. У Марка был список слов, которыми нельзя было называть переменные. Да, часть из них была из списка ключевых слов языка, но примерно половина — это были просто слова, которые не нравились лично Марку. Он определял вещи вроде того, в каком именно месте нужно переносить длинные строки, в каких случаях какие нужны отступы и т.д.
Я просто бесился от всего этого. Эти два пробела, эти запрещенные слова — ну что за чушь! Некоторые правила были вроде бы безвредные — вроде переноса строки Then на следующую строку после If. Но сам факт появления в этом случае новой строки опять приводил к добавлению этих двух пробелов, что снова выводило меня из себя.
Но что я мог поделать? Марк был моим непосредственным начальником, это была моя первая работа после университета, а на дворе была рецессия 80-ых годов. На рынке труда без работы болтались тысячи квалифицированных программистов, так что я попросту не мог рисковать.
Я не говорю, что я не возражал — мой характер попросту иногда не давал мне промолчать. Но всё же я никогда не доводил споры до острой фазы. Ну и поскольку Марк оставался моим боссом, а его приверженность стандартам никуда не девалась — со временем эти стандарты стали моей второй натурой. Ещё позже я осознал, что о них можно думать и в другом ключе. Стандарты не ограничивали полёт моей фантазии, они давали мне возможность творить в их рамках, что тоже могло доставлять удовольствие.
Если вы посмотрите на творчество известных художников, то заметите, что именно накладывание некоторых рамок на творчество часто было залогом создания шедевров. Люди творчества часто идут на эти ограничения сознательно — так они получают контекст для своего творчества. Я не считаю разработку программного обеспечения на 100% искусством, но в хорошем коде можно увидеть творчество.
Спустя несколько месяцев моей работы с Марком, по ходу которой я впитал все эти стандарты кодирования, нашу компанию купила и поглотила другая компания. Марк, я и ещё несколько человек успешно пережили этот процесс. Мы все переехали из Миннесоты в Бирмингем, но это уже другая история. Я лишь скажу, что культурные различия между некоторыми штатами иногда бывают похлеще, чем между США и Европой.
Компания, которая приобрела мою первую фирму, тоже занималась разработкой ПО. Количество сотрудников также было сопоставимо. Но у них не было вообще никаких стандартов кодирования. Они тоже писали под DEC VAX, они тоже использовали VAX Basic. Но каждый разработчик писал так, как хотел и не обращал никакого внимания на код остальных людей.
Один из программистов начинал с FORTRAN. Он обнаружил, что код на VAX Basic можно писать в стиле FORTRAN (а вы помните, что DEC тщательно перетащила в Basic большинство возможностей FORTRAN) — так что код вполне себе компилировался и работать.
Другой разработчик учился программировать на Apple ][ и в его коде на VAX Basic были номера строк. Я не шучу! Как в Applesoft!
Все в этой конторе писали по-разному, кардинально по-разному. Некоторые тащили за собой что-то древнее, а кто-то использовал новые подходы. Позже выяснилось, что они делали это специально. Частично потому, что никто из них не хотел учиться чему-то новому, а частично потому, что это давало им некоторую безопасность (пока никто, кроме тебя, не понимает твой код, а его надо поддерживать — тебя не уволят).
Это было полной противоположностью привычному мне миру Марка, где было невозможно сказать, кто написал ту или иную строку кода, поскольку каждая строка чётко соответствовала одному и тому же стандарту.
И это был момент, когда меня озарило первое в моей профессиональной жизни прозрение. Да, строго соответствовать стандартам кодирования — нелегко, но альтернативы — значительно хуже!
С тех пор в каждом проекте, в котором я работал, я старался продвигать идею применения строгих стандартов и стилей программирования. И даже некоторые странности в стандартах (вроде двух пробелов после табуляции — что очень, очень, очень глупо!) намного лучше, чем вообще никаких стандартов. И я буду яростно поддерживать даже эти 2 пробела, если единственной альтернативой будет хаос.
Я, конечно, на этапе обсуждения стандартов стараюсь находить и критиковать явно плохие вещи, но как только решение принято — оно принято, и я становлюсь самым яростным его защитником.
Я многому научился у Марка. Что-то было хорошим, что-то — плохим. Но его приверженность стандартам очень сильно сформировала моё представление о качественном программном обеспечении.
Комментарии (4)
vlreshet
22 февраля 2017 в 17:54 (комментарий был изменён)
+1↑
↓
/offtop Кстати, что интересно, во многих университетах СНГ (я не говорю что во всех) никто не учит понятию codestyle. Нет, заикаются, бывает, но по факту никто за этим не следит — главное чтобы работа студента работала (каламбур-с), а как — неважно. И потом на свет выходят вчерашние студенты — сегодняшние программисты которые вроде как и умеют что-то, но их код полон вещей типаif(peremennaya1) poschitatDannye(dannye);
И это печально. Есть люди которые всерьёз не понимают зачем нужен codestyle.22 февраля 2017 в 18:26
0↑
↓
Отличная статья! Подобное прозрение посетило меня через неделю работы с Golang: стандарт кода вшитый в язык! Никаких больше холиваров об отступах, уверенность, что когда откроешь код чужого пакета, там будет все в знакомом и читаемом виде!
Каждому языку хорошо бы иметь стандарт вида и стиля кода. Правда нам, разработчикам, это часто не нравится, мол, ограничивает свободу. Хотя, на мой взгляд, это скорее перенос акцентов с стиля кода на его работу и содержание.22 февраля 2017 в 18:27 (комментарий был изменён)
0↑
↓
Ну, справедливости ради — не Golang это придумал, как минимум с Python всё началось, а может и раньше.
22 февраля 2017 в 19:28
0↑
↓
Вместо того, чтобы слепо следовать указаниям непонятного супер-программиста Марка (который тоже может ошибаться), я предпочитаю заставлять всех своих программистов следовать стандартам кодирования, разработанными не самыми мелкими и уважаемыми организациями. Так больше вероятность, что выработанные ими стандарты логичны. Например NASA и JPL регулярно публикуют стандарты кодирования Си. Сейчас у них есть и Java.
http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
http://www.havelund.com/Publications/jpl-java-standard.pdf
