Мы тогда писали под 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 пробела, если единственной альтернативой будет хаос.
Я, конечно, на этапе обсуждения стандартов стараюсь находить и критиковать явно плохие вещи, но как только решение принято — оно принято, и я становлюсь самым яростным его защитником.
Я многому научился у Марка. Что-то было хорошим, что-то — плохим. Но его приверженность стандартам очень сильно сформировала моё представление о качественном программном обеспечении.
Комментарии (67)
JekaMas
22.02.2017 18:26+2Отличная статья! Подобное прозрение посетило меня через неделю работы с Golang: стандарт кода вшитый в язык! Никаких больше холиваров об отступах, уверенность, что когда откроешь код чужого пакета, там будет все в знакомом и читаемом виде!
Каждому языку хорошо бы иметь стандарт вида и стиля кода. Правда нам, разработчикам, это часто не нравится, мол, ограничивает свободу. Хотя, на мой взгляд, это скорее перенос акцентов с стиля кода на его работу и содержание.tangro
22.02.2017 18:27+4Ну, справедливости ради — не Golang это придумал, как минимум с Python всё началось, а может и раньше.
aamonster
22.02.2017 20:27Где-то читал, что Гвидо ван Россум сильно жалел, что разрешил и табы, и пробелы. Не вполне похоже на вшитый стандарт кода.
А вот автоформаттеры давно были, вроде ещё в досовские времена.
khim
22.02.2017 20:32Нету у python аналога «go fmt». Не знаю, кто первый это придумал, но Go — единственный популярный язык, где это приходит из коробки. Хотя в IDE для Java это появилось раньше, но там — это часть среды, оно в комплект компилятора не входит.
Для C/C++ есть clang-format. Мне тоже часто не нравится то, что он делает, но если альтернатива — хаос или долгие разборки на тему «а нужно тут ставить два пробела или один?», то… ну его нафиг. Что clang-format сделал — то и будет. Точка.
BekoBou
23.02.2017 03:15+1Так PEP8 можно считать таким стандартом. Понятно, что он не тако жёсткий и даже там есть где немного срезать углы, но на работе у меня в редакторе по сохранению стоит выполнение autopep8 с конфигом, о котором договорились. Вот тебе и стандарт, вот тебе и автоматическое форматирование.
Если добавить к этому .editorconfig, то жить становится совсем просто.
JekaMas
23.02.2017 20:55Кстати да! И тоже касается goimports — порядок импортов, их разбиение на блоки тоже определено стандартными инструментами.
Более строго было, пожалуй, только во времена Pascal и его родственников.
После PHP, где хотя и есть несколько стандартов, но их далеко не везде придерживаются, любой стандарт — это благо. Особенно если не нужен никакой тимлид, принуждающий ему следовать. Стандарт оформления кода — это тоже часть языка, на мой взгляд.
lingvo
22.02.2017 19:28+3Вместо того, чтобы слепо следовать указаниям непонятного супер-программиста Марка (который тоже может ошибаться), я предпочитаю заставлять всех своих программистов следовать стандартам кодирования, разработанными не самыми мелкими и уважаемыми организациями. Так больше вероятность, что выработанные ими стандарты логичны. Например 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
AxianLTD
23.02.2017 07:19Угу, только в то время еще небыло всяких уважаемых организаций…
Единственный документ, который был доступен, по крайней мере нам, был C-style sheet. Вот ему и следовали.
dmitry_dvm
22.02.2017 20:08А есть ли в паблике стандарты Майкрософта? Наверняка же у них есть корпоративные правила, вот бы посмотреть. Интересует C#, в частности.
nuald
22.02.2017 21:53+1Здесь достаточно интересная история. Она начинается в 2008 году, когда было объявлено о публикации StyleCop, инструменте, используемом в MS для проверки соответствия их стандартом. Инструмент до сих пор используется — StyleCop Analyzers, и список правил (не особо оформленный правда, причину см. ниже) доступен на сайте: https://stylecop.pdelvo.com/
Но в 2015 году, возможно из-за внутренних пертурбаций, стандарты поменялись — Automatic code formatter released to GitHub. Основное отличие, на которое все жалуются — это использование подчеркивания вместо «this.», как это было рекомендовано StyleCop. Тем не менее, на текущий момент рекомендуется использовать именно эти новые стандарты кодирования. Учтите, что это внутренние стандарты, Microsoft не публиковало каких-либо официальных стандартов для внешнего использования, так что используете эти инструменты на свое усмотрение.
pankraty
23.02.2017 10:53Собственно, вот.
Есть еще Design Guidelines for Class Library Developers, которые зачастую берутся за основу для coding conventions на крупных проектах.
imbasoft
22.02.2017 20:09Стиль программирования определяется менталитетом программиста. Некоторые неплохие программеры не могут следовать стандартам, у них начинается внутренний конфликт который поглощает все их внимание, что резко сказывается на работе.
В таких случаях иногда идут дальше и в команде появляется человек ответственный за унификацию кода и документации.
А вообще без стандартизации в командной работе никуда.khim
22.02.2017 20:42+4Самая большая проблема, с которой я сталкивался в командной работе — это «у нас так принято». Ничего не выбешивает больше, чем подобные заявляения.
Ребята, если вы хотите, чтобы я не использовал локальные переменные типа «host_pointer_to_locked_guest_structure_xxx», то напишите, блин, об этом где-нибудь. Если у вас есть соглашения о том как должны называться геттеры/сеттеры, то об этом необходимо написать в стайл-гайде.
Не разводите сектанство! У нас, конечно, свобода вероисповедания, но… в нерабочее время, пожалуйста!
P.S. Особенно доставляет когда в ответ на эту просьбу я слышу «ну, у нас и так большой стайл-гайд, мы не хотим его засорять мелочами». Либо это для вас неважно, «мелочи» — и тогда не стоит на это жаловаться на каждом code review, либо важно — и тогда пусть в стайл-гайде будет 1000 страниц. Выискивать вот эти вот «у нас так принято» постепенно узнавая у гуру «а как у нас принято» — куда сложнее, чем прочитать самый объемный style guide!amaslenn
23.02.2017 22:18А вы этот гайд на 100 страниц читать будете? На ревью, конечно, приятнее получить ссылку на документ, чем простое "у нас так принято", но легче не станет, мне кажется.
Сам я за жесткие автоматические проверки на стадии CI. Зачем спорить о том, что могут проверить машины?khim
23.02.2017 22:36+1А вы этот гайд на 100 страниц читать будете?
Да, буду. Могу, конечно, что-то и забыть, но в любом случае это гораздо лучше чем попытки выяснить — это точно так принято или, может быть, только прихоть ревьюера, и что вообще этим делать.
На ревью, конечно, приятнее получить ссылку на документ, чем простое «у нас так принято», но легче не станет, мне кажется.
Станет. Потому что если это мало-мальски вразумительный гайд, то там будет хотя бы формулировка того, «что у нас принято».
И, главное, это позволяет отделить «у нас так принято» от «мне так нравится». Моя задача, в общем-то не состоит в том, чтобы ублажать ревьюера. А с «у нас так принято» зачастую подавляющее большинство замечаний невозможно даже описать человеческим языком.
daiver19
24.02.2017 00:33Тут есть одна тонкость: скорее всего «у нас так принято» это сокращенная версия «это консистентно остальному коду проекта». Всегда поражался людям которые модифицируя кода ленятся посмотреть на стиль используемый буквально в двух строках выше. Грубый пример — стайлгайд позволяет ставить звездочку как с пробелом после типа, так и без, весь код проекта использует один из вариантов, а некто берет и использует другой.
khim
24.02.2017 03:53Всегда поражался людям которые модифицируя кода ленятся посмотреть на стиль используемый буквально в двух строках выше.
А в двух строках ниже? А в соседнем файле? Мне статанализ проводить перед тем изменение на две строчки написать?
Тут есть одна тонкость: скорее всего «у нас так принято» это сокращенная версия «это консистентно остальному коду проекта».
Точно-точно? И нигде других вариантов нету? Ну так впишите это в стайл гайд. Или есть и вы не хотите с этим заморачиваться? Ну а тогда почему я должен?
Грубый пример — стайлгайд позволяет ставить звездочку как с пробелом после типа, так и без, весь код проекта использует один из вариантов, а некто берет и использует другой.
Именно. Это — как раз пример, который выбешивает меня, да: если в стайлгайде разрешили почему-то оба варианта, то зачем-то они ведь это сделали?
Если clang-format поправит (а он это любит) — ну Ok, но если нет — то причём тут я?daiver19
24.02.2017 11:45Ну у нас вот говорится, что консистетность первыше всего :) По поводу анализа — не доводите до абсурда. Обычно достаточно пары строк из того же файла. А дальше по индукции все будет консистентно.
khim
24.02.2017 23:12Ну у нас вот говорится, что консистетность первыше всего :)
Что интересно — я исхожу из ровно тех же соображений. И меня, кстати, поддерживают, создатели нашего стайл-гайда.
Если вы вводите какие-то правила «у нас так принято» в команде, то ваш кода становится неконсистентным по отношению ко всей компании!
Потому если хотите изменять правила — в соответствующий список рассылки!daiver19
24.02.2017 23:21Речь о местах не заданных явно в стайлгайде. Почему так — понятия не имею. В любом случае, есть куча мест, в которых стайлгайд не поможет (касательно вопросов несколько сложнее, чем число пробелов). Так что надо просто учиться писать консистентно.
redmanmale
24.02.2017 11:51Этот гайд импортируется в IDE и спокойно поддерживается, и не надо 1000 страниц читать.
PsyHaSTe
02.03.2017 20:11Всё так. Восславим анализаторы IDE, особенно те, которые позволяют кастомизацию (привет, Roslyn)
meta4
22.02.2017 20:44+7
khim
22.02.2017 20:55+3Я бы сказал что этот стиль очень тяжело поддерживать руками. Но если ему научить clang-format… Почему нет? Лаконично и достаточно удобно — при условии, что можно быть уверенным что все точки с запятой и фигурные скобки соответствуют отступам.
alexeiz
25.02.2017 09:26Ага, попробуй clang-format научить такому. Он твои паспортные данные автоматически пошлёт в ближайшую псих-больницу.
На самом деле, если не хочешь видеть точки с запятой и фигурные скобки, то можно просто в редакторе задать для них цвет, который почти не отличается от фона. Такой подход отлично работает, например, в Лиспе, где скобок дофига и больше.
ConceptDesigner
23.02.2017 01:29+1Как же я понимаю автора! Тема весьма и весьма актуальна для командной разработки. Больше всего добивает ситуация, когда в команду приходит новый разработчик и говорит: «Мне пофиг на ваш codestyle, я привык писать в стиле Керниган и Ричи». И начинается очередной локальный холивар.
khim
23.02.2017 02:02Да пусть пишет хоть в стиле зелёной обезьяны, но что прописано в правилах — должно быть исполнено.
Если окажется что даже после этого его код вы не воспринимаете — ну добавьте пару новых пунктов в список.
Это как раз не страшно, страшно когда приходишь — а как писать тебе не говорят, говорят «ну тут же всё очевидно», а потом программа в 10 строк обсуждается неделю, потому что в ней нарушены 100500 неписанных правил.
Правила должны быть писанными — это облегчает жизнь всем.
ferreto
23.02.2017 10:55+1А вот я и сейчас вынужден следовать стандартам похожим на стандарты того Марка. Проекту несколько десятилетий, древний язык программирования. Есть толмуд по этим кем-то придуманным стандартам. Вплодь до того, сколько пробелов должно быть перед каждой командой, с какого столбца должны начинаться комментарии и так далее… Но это все можно понять — программисты приходят и уходят, а проект на Cobol вечен! Пришёл новый программист, прочитал доку по стандартам и пишет. Следующему будет всё ясно. Заказчиков можно понять. Или хаос или тупые стандарты...
leocat33
23.02.2017 23:04Стандарты на отступы были обусловлены применением перфокарт.
Цитата из вики (про FORTRAN IV):
Структура программ изначально была ориентирована на ввод с перфокарт и имела ряд удобных именно для этого случая свойств. Так, с 1-й по 5-ю колонку располагалась область меток, 6-я служила для маркировки текста как продолжения предыдущей строки (любым символом, кроме пробела и «0»), а с 7-й по 72-ю располагался собственно текст оператора или комментария. Колонки с 73-й по 80-ю могли служить для нумерации карт (чтобы восстановить случайно рассыпавшуюся колоду) или для краткого комментария, транслятором они игнорировались.
Табулятор трактовался как 4 пробела. 1 пробел как разделитель, второй пробел как продолжение оператора. Итого=6. Можно конечно и 6 пробелов «настучать»…
Среды программирования на VAX-ах были. Тут автор «загнул». Например EVE чего стоит (включал в себя TPU) и кстати, в VMS жив по сей день…
uldashev
23.02.2017 10:55+1А не проще один раз написать автоматический форматтер кода и пусть каждый пишет как ему нравится, в мастер ветке все равно будет единый формат?
khim
23.02.2017 14:02Автоматический форматтер будет переменные переименовывать или «auto» на конкретные типы заменять там, где гайд этого требует?
Пробелы автоматом расставить — это да, очень пользительно.
amarao
23.02.2017 16:45+3Когда стайлгайд энфорсится человеком, это выглядит как насилие и произвол. Когда стайлгайд энфорсится хуком в гите, реджектящим пуш, это выглядит как часть условностей софта, к которым привыкаешь.
alexeiz
25.02.2017 09:41Все эти гайды — фигня полная. В моей практике, гайдами всегда все недовольны, кроме самих писателей гайдов. Поэтому в компании, где я сейчас работаю, я сделал так:
- есть всего несколько жестких правил: no tabs, line ending
- хороший код важнее хорошо отформатированного кода
- на ревью, я всем советую обращать внимание на то, что код делает, а не сколько пробелов в операторе if
- я написал, clang-format конфиг, который позволяет отформатировать код приличным образом
- если кому-то хочется гайда, он просто берет этот конфиг и форматирует свой код автоматически
- если кто вообще пофигист и пишет, как курица лапой, то я сам прогоняю его код через clang-format, даже не спрашивая
- ему всё равно пофиг, поэтому конфликтов на этой почве не возникает
- не было ещё ни одного спора по поводу этого гайда, потому что гайда как такового почти и нет
khim
25.02.2017 19:01+1Нифига же себе «у нас нет гайда»! Полстраны на описание того, чего нет. И главное в вашем гайде — это таки clang-format.
У нас довольно большой гайд, но удивительным образом баталий на тему важных вещей (правил использованияauto, к примеру) — всегда было не так много. А вот по поводу отступов… bikeshedding, как он есть… Clang-format эту проблему успешно решает.
kmmbvnr
28.02.2017 10:34Не заметил в обсуждении, два важных факта:
1. Код — собственность компании. В интересах компании сделать программистов взаимозаменяемыми. Отсюда и общее владение кодом, когда любой может залезть и исправить любой кусок и стайлгайд. Компания решила применять стайлгайд — придется следовать. Тут нет месту холиварам.
2. Многие программисты немного аутисты. Они чувствуют себя лучше когда строго следуют определенному набору правил. И наоборот, если что-то не так, настроение у них портится сильно больше, чем того заслуживает неправильный отступ или перенос.
Марк из статьи похоже был конктетным аутистом. Но в коллективе из аутистов любые правила, лучше их отсутствия.
vlreshet
/offtop Кстати, что интересно, во многих университетах СНГ (я не говорю что во всех) никто не учит понятию codestyle. Нет, заикаются, бывает, но по факту никто за этим не следит — главное чтобы работа студента работала (каламбур-с), а как — неважно. И потом на свет выходят вчерашние студенты — сегодняшние программисты которые вроде как и умеют что-то, но их код полон вещей типа
if(peremennaya1) poschitatDannye(dannye);
И это печально. Есть люди которые всерьёз не понимают зачем нужен codestyle.
impwx
У нас на кафедре был парень, у которого весь код дипломного проекта был в методе
Button1_Click(). И он защитился.Так что оформление — отличный показатель, по которому можно отличить людей, которые действительно пригодны к профессии. Практика показывает, что если человек не следует правилам оформления и именования, то ни о какой надежности или грамотной архитектуре в его коде речь вообще не идет.
JediPhilosopher
До тех пор пока ты только и делаешь что курсовики и дипломы в одиночку — т.е. нет проблемы ни поддержки написанного кода через год-другой (ты его сдашь, получишь свой зачет и выбросишь нафиг), ни взаимодействия в команде — то это норм. В смысле нет никакого стимула тратить дополнительное время на изучение и соблюдение стандартов кодирования если только их в явном виде не требуют при сдаче задания. Да и даже если требуют — одно дело формально прочитать про это где-то и формально же выполнить, а другое дело — понять зачем это было нужно на своем опыте.
И путь автора статьи совершенно типичен в этом плане, нужность таких вещей можно понять и прочувствовать только на своем опыте, побарахтавшись для начала в океане Г где их не используют и сравнив ощущения.
Поэтому требовать от студентов без опыта реальной работы всего этого мне кажется бессмысленным.
ftdgoodluck
Но согласитесь – было бы здорово, если бы стандарты преподавали, и тогда студент, завершивший довольно большую работу, был бы гораздо лучше готов к реальной работе.
KongEnGe
Чтобы преподавать стандарты (и спрашивать за их знание), их нужно иметь. А в индустрии стандарты все равно корпоративно-зависимые.
Так что только лирическим отступлением на лекции о пользе единообразия в коде.
maz_d
какие стандарты? они ведь разные в разных языках/компаниях/проектах. Имхо в 90% случаев все равно человеку придется переучиваться, а когда ему эти стандарты будут вбивать в голову он все равно без опыта реальных проектов не будет понимать зачем это надо.
impwx
Хорошо бы давать задания на командную работу — настроить окружение, завести репозиторий, поделить задачи. Это наглядно покажет, зачем нужны стандарты — да и само по себе очень полезная практика, которую всегда спрашивают при приеме на работу.
JediPhilosopher
К сожалению оно не работает. Если давать задание на группу из 2-3 человек, то почти всегда получается так что один делает всю работу, а остальные ему проставляются. Ну или если и помогают то совсем чуть-чуть. Опять же довольно жестко ограничены размеры такого проекта — большие нельзя давать, их вообще никто не сделает так как времени нет. Ведь есть еще и другие предметы. А на маленьких краткосрочных проектах опять же все проблемы с отсутствием тестирования, code style и прочих полезных вещей, обычно не проявляются в достаточной степени чтобы убедить ими пользоваться.
impwx
Вполне работает — но нужен принципиальный преподаватель. У нас в вузе делалось вот так:
Задание на курсовой проект — написать сервер и два клиента на разных технологиях, взаимодействующие по протоколу SOAP. Предметная область — любая, для простоты большинство выбрало todo list. Студенты объединяются в группы по 3-4 человека и этой же группой сдают: преподаватель выбирает случайные места в коде и просит каждого по очереди рассказать, что тут происходит. Если студент не отвечает, вся группа теряет половину балла.
В такой ситуации умному студенту невыгодно брать в команду «балласт» — из-за него можно получить низкий балл. Поэтому группы были «ровные» — либо все что-то делают, либо никто.
Сейчас помимо этого можно также проверить лог коммитов в репозитории. Конечно, лог можно и сфабриковать. Но имхо для студента, который может это сделать, написать всё по-честному тоже не составит большого труда.
Neftedollar
удалено
impwx
Если студент за время обучения прогает только курсовые, да и те спустя рукава — шанс найти работу по специальности исчезающе мал. Высшее образование для этого не достаточно и даже не необходимо. Оно помогает систематизировать фундаментальные знания, не меняющиеся между языками и платформами (сложности алгоритмов, структуры данных и т.д.), но чтобы их применить, нужны практические навыки и внутренняя мотивация. А существующая система построена таким образом, что пока по технологии сделают, одобрят и начнут преподавать курс — она уже морально устареет.
Guzergus
По своему опыту, курсовая и диплом приличных размеров уже куда сложнее поддерживать, если всё, условно, в одном методе. Если у человека за несколько лет не возникает мысли, как можно сделать лучше и удобнее, и он всё делает абы как — вряд ли из него получится хороший специалист, IMHO.
Более того, студенты могут не иметь реального коммерческого опыта, но тем не менее участвовать в командных проектах, где необходимость примитивного code style и дизайна ещё более заметна.
Возможно, я предвзят, потому что лично мне неприятно читать Button1_click в любом проекте, который чуть дольше «открыл среду и что-то проверил», и такое отношение у меня было ещё с первых-вторых курсов университета.
devalone
Большинство студентов ничего такого, где нужна правильная архитектура, не пишут и весь код у них помещается в Button1_Click() и тот, кто его написал, может его понять, поэтому сам он и не задумывается, о том, чтобы писать хорошо, а если ещё и преподаватели не пинают, то и подавно.
Ну, тут можно поспорить, я видел у одногруппников хорошо оформленный говнокод.
iburyl
Наиболее существенная ценность в цафиксированном стиле кодирования — упрощение поддержки кода. Боль поддержки кода очень сложно передать в университете. Осознание приходит с опытом (о чём и статья).
elmm
У меня сокурсник отступы в C/C++ коде ставил, такое ощущщение, что на основе случайных чисел.
Мог пяток вызовов в одну строку слепить. Код лабораторок выглядел как после обфускации и преподователи за голову хватались, когда пытались понять, что там написанно :)
Причём чувак был умный, но вот с форматиованием такие косяки.
Я думаю таких историй у каждого масса наберётся.
quwy
У меня жена так пишет. Просто где курсор оказывается после ативации окна редактора мышкой, там и пишется код. Бороться совершенно бесполезно, пользуемся автоформаттером если код общий или публичный.
devalone
Хорошо, когда преподаватели за голову хватаюстя, а у меня вот преподаватель по ООП пишет «обфусцированный» код, переменные типа a, b1, dx, логика в обработчиках событий и прочий ужас, зато с отступами и форматированием никаких проблем.
vbif
На прошлой работе у меня так писали тимлид и основатель компании.
MacIn
Эмм да, вам бы посмотреть на наш первый курс, предмет «Алгоритмизация и структурное программирование» на основе Паскаля. Вела пожилая преподавательница, придиралась к каждой запятой, отступу, пробелу, именам переменных, длине методов и так далее. Все «по жести». Кто ее прошел, тому уже никакой матан и линейка не страшны. Питер.
DartNyan
У нас на первом курсе один преподаватель настойчиво заставлял нас придерживаться некоторых правил оформления. Оформляли код не так, как она хочет — минус бал или несколько и мини скандал в придачу. Придирки были в стиле:
Типа без блока в виде { } программа будет быстрее.
Попытка оспорить какие-то ее правила синтаксиса, как уже упомянул выше, приводила к снижению оценки и ссоре. Некоторым ребятам потом после нее было трудно переучиваться.
Oxoron
Пардон, а для какого языка и компилятора это будет быстрее?
И почему быстродействие кода ставится выше его поддерживаемости (первый вариант чуть менее устойчив к добавлению строк)?
Я понимаю, что это преподавательница спрашивала, но надеюсь она как-то аргументировала эти правила.
DartNyan
Боюсь, что я не смогу ответить на этот вопрос. :)
Свято верила в то, что это быстрее и читабельнее. И не только в это.
Pakos
Переубедил когда-то подобном преподавателя, продемонстрировав ассемблерный код обоих вариантов (не по форматированию, но тоже пытался убедить на пальцах). Но там можно было убедить.