Комментарии 68
НЛО прилетело и опубликовало эту надпись здесь
У нас на кафедре был парень, у которого весь код дипломного проекта был в методе
Так что оформление — отличный показатель, по которому можно отличить людей, которые действительно пригодны к профессии. Практика показывает, что если человек не следует правилам оформления и именования, то ни о какой надежности или грамотной архитектуре в его коде речь вообще не идет.
Button1_Click(). И он защитился.Так что оформление — отличный показатель, по которому можно отличить людей, которые действительно пригодны к профессии. Практика показывает, что если человек не следует правилам оформления и именования, то ни о какой надежности или грамотной архитектуре в его коде речь вообще не идет.
До тех пор пока ты только и делаешь что курсовики и дипломы в одиночку — т.е. нет проблемы ни поддержки написанного кода через год-другой (ты его сдашь, получишь свой зачет и выбросишь нафиг), ни взаимодействия в команде — то это норм. В смысле нет никакого стимула тратить дополнительное время на изучение и соблюдение стандартов кодирования если только их в явном виде не требуют при сдаче задания. Да и даже если требуют — одно дело формально прочитать про это где-то и формально же выполнить, а другое дело — понять зачем это было нужно на своем опыте.
И путь автора статьи совершенно типичен в этом плане, нужность таких вещей можно понять и прочувствовать только на своем опыте, побарахтавшись для начала в океане Г где их не используют и сравнив ощущения.
Поэтому требовать от студентов без опыта реальной работы всего этого мне кажется бессмысленным.
И путь автора статьи совершенно типичен в этом плане, нужность таких вещей можно понять и прочувствовать только на своем опыте, побарахтавшись для начала в океане Г где их не используют и сравнив ощущения.
Поэтому требовать от студентов без опыта реальной работы всего этого мне кажется бессмысленным.
Но согласитесь – было бы здорово, если бы стандарты преподавали, и тогда студент, завершивший довольно большую работу, был бы гораздо лучше готов к реальной работе.
Чтобы преподавать стандарты (и спрашивать за их знание), их нужно иметь. А в индустрии стандарты все равно корпоративно-зависимые.
Так что только лирическим отступлением на лекции о пользе единообразия в коде.
Так что только лирическим отступлением на лекции о пользе единообразия в коде.
какие стандарты? они ведь разные в разных языках/компаниях/проектах. Имхо в 90% случаев все равно человеку придется переучиваться, а когда ему эти стандарты будут вбивать в голову он все равно без опыта реальных проектов не будет понимать зачем это надо.
Хорошо бы давать задания на командную работу — настроить окружение, завести репозиторий, поделить задачи. Это наглядно покажет, зачем нужны стандарты — да и само по себе очень полезная практика, которую всегда спрашивают при приеме на работу.
К сожалению оно не работает. Если давать задание на группу из 2-3 человек, то почти всегда получается так что один делает всю работу, а остальные ему проставляются. Ну или если и помогают то совсем чуть-чуть. Опять же довольно жестко ограничены размеры такого проекта — большие нельзя давать, их вообще никто не сделает так как времени нет. Ведь есть еще и другие предметы. А на маленьких краткосрочных проектах опять же все проблемы с отсутствием тестирования, code style и прочих полезных вещей, обычно не проявляются в достаточной степени чтобы убедить ими пользоваться.
Вполне работает — но нужен принципиальный преподаватель. У нас в вузе делалось вот так:
Задание на курсовой проект — написать сервер и два клиента на разных технологиях, взаимодействующие по протоколу SOAP. Предметная область — любая, для простоты большинство выбрало todo list. Студенты объединяются в группы по 3-4 человека и этой же группой сдают: преподаватель выбирает случайные места в коде и просит каждого по очереди рассказать, что тут происходит. Если студент не отвечает, вся группа теряет половину балла.
В такой ситуации умному студенту невыгодно брать в команду «балласт» — из-за него можно получить низкий балл. Поэтому группы были «ровные» — либо все что-то делают, либо никто.
Сейчас помимо этого можно также проверить лог коммитов в репозитории. Конечно, лог можно и сфабриковать. Но имхо для студента, который может это сделать, написать всё по-честному тоже не составит большого труда.
Задание на курсовой проект — написать сервер и два клиента на разных технологиях, взаимодействующие по протоколу SOAP. Предметная область — любая, для простоты большинство выбрало todo list. Студенты объединяются в группы по 3-4 человека и этой же группой сдают: преподаватель выбирает случайные места в коде и просит каждого по очереди рассказать, что тут происходит. Если студент не отвечает, вся группа теряет половину балла.
В такой ситуации умному студенту невыгодно брать в команду «балласт» — из-за него можно получить низкий балл. Поэтому группы были «ровные» — либо все что-то делают, либо никто.
Сейчас помимо этого можно также проверить лог коммитов в репозитории. Конечно, лог можно и сфабриковать. Но имхо для студента, который может это сделать, написать всё по-честному тоже не составит большого труда.
Если студент за время обучения прогает только курсовые, да и те спустя рукава — шанс найти работу по специальности исчезающе мал. Высшее образование для этого не достаточно и даже не необходимо. Оно помогает систематизировать фундаментальные знания, не меняющиеся между языками и платформами (сложности алгоритмов, структуры данных и т.д.), но чтобы их применить, нужны практические навыки и внутренняя мотивация. А существующая система построена таким образом, что пока по технологии сделают, одобрят и начнут преподавать курс — она уже морально устареет.
По своему опыту, курсовая и диплом приличных размеров уже куда сложнее поддерживать, если всё, условно, в одном методе. Если у человека за несколько лет не возникает мысли, как можно сделать лучше и удобнее, и он всё делает абы как — вряд ли из него получится хороший специалист, IMHO.
Более того, студенты могут не иметь реального коммерческого опыта, но тем не менее участвовать в командных проектах, где необходимость примитивного code style и дизайна ещё более заметна.
Возможно, я предвзят, потому что лично мне неприятно читать Button1_click в любом проекте, который чуть дольше «открыл среду и что-то проверил», и такое отношение у меня было ещё с первых-вторых курсов университета.
Более того, студенты могут не иметь реального коммерческого опыта, но тем не менее участвовать в командных проектах, где необходимость примитивного code style и дизайна ещё более заметна.
Возможно, я предвзят, потому что лично мне неприятно читать Button1_click в любом проекте, который чуть дольше «открыл среду и что-то проверил», и такое отношение у меня было ещё с первых-вторых курсов университета.
Большинство студентов ничего такого, где нужна правильная архитектура, не пишут и весь код у них помещается в Button1_Click() и тот, кто его написал, может его понять, поэтому сам он и не задумывается, о том, чтобы писать хорошо, а если ещё и преподаватели не пинают, то и подавно.
Ну, тут можно поспорить, я видел у одногруппников хорошо оформленный говнокод.
Так что оформление — отличный показатель, по которому можно отличить людей, которые действительно пригодны к профессии
Ну, тут можно поспорить, я видел у одногруппников хорошо оформленный говнокод.
Наиболее существенная ценность в цафиксированном стиле кодирования — упрощение поддержки кода. Боль поддержки кода очень сложно передать в университете. Осознание приходит с опытом (о чём и статья).
У меня сокурсник отступы в C/C++ коде ставил, такое ощущщение, что на основе случайных чисел.
Мог пяток вызовов в одну строку слепить. Код лабораторок выглядел как после обфускации и преподователи за голову хватались, когда пытались понять, что там написанно :)
Причём чувак был умный, но вот с форматиованием такие косяки.
Я думаю таких историй у каждого масса наберётся.
Мог пяток вызовов в одну строку слепить. Код лабораторок выглядел как после обфускации и преподователи за голову хватались, когда пытались понять, что там написанно :)
Причём чувак был умный, но вот с форматиованием такие косяки.
Я думаю таких историй у каждого масса наберётся.
НЛО прилетело и опубликовало эту надпись здесь
Хорошо, когда преподаватели за голову хватаюстя, а у меня вот преподаватель по ООП пишет «обфусцированный» код, переменные типа a, b1, dx, логика в обработчиках событий и прочий ужас, зато с отступами и форматированием никаких проблем.
На прошлой работе у меня так писали тимлид и основатель компании.
Эмм да, вам бы посмотреть на наш первый курс, предмет «Алгоритмизация и структурное программирование» на основе Паскаля. Вела пожилая преподавательница, придиралась к каждой запятой, отступу, пробелу, именам переменных, длине методов и так далее. Все «по жести». Кто ее прошел, тому уже никакой матан и линейка не страшны. Питер.
У нас на первом курсе один преподаватель настойчиво заставлял нас придерживаться некоторых правил оформления. Оформляли код не так, как она хочет — минус бал или несколько и мини скандал в придачу. Придирки были в стиле:
Типа без блока в виде { } программа будет быстрее.
Попытка оспорить какие-то ее правила синтаксиса, как уже упомянул выше, приводила к снижению оценки и ссоре. Некоторым ребятам потом после нее было трудно переучиваться.
// это лучше
if (foo)
doSomething();
// чем это
if (foo) {
doSomething();
}
Типа без блока в виде { } программа будет быстрее.
Попытка оспорить какие-то ее правила синтаксиса, как уже упомянул выше, приводила к снижению оценки и ссоре. Некоторым ребятам потом после нее было трудно переучиваться.
Пардон, а для какого языка и компилятора это будет быстрее?
И почему быстродействие кода ставится выше его поддерживаемости (первый вариант чуть менее устойчив к добавлению строк)?
Я понимаю, что это преподавательница спрашивала, но надеюсь она как-то аргументировала эти правила.
И почему быстродействие кода ставится выше его поддерживаемости (первый вариант чуть менее устойчив к добавлению строк)?
Я понимаю, что это преподавательница спрашивала, но надеюсь она как-то аргументировала эти правила.
Отличная статья! Подобное прозрение посетило меня через неделю работы с Golang: стандарт кода вшитый в язык! Никаких больше холиваров об отступах, уверенность, что когда откроешь код чужого пакета, там будет все в знакомом и читаемом виде!
Каждому языку хорошо бы иметь стандарт вида и стиля кода. Правда нам, разработчикам, это часто не нравится, мол, ограничивает свободу. Хотя, на мой взгляд, это скорее перенос акцентов с стиля кода на его работу и содержание.
Каждому языку хорошо бы иметь стандарт вида и стиля кода. Правда нам, разработчикам, это часто не нравится, мол, ограничивает свободу. Хотя, на мой взгляд, это скорее перенос акцентов с стиля кода на его работу и содержание.
Ну, справедливости ради — не Golang это придумал, как минимум с Python всё началось, а может и раньше.
Где-то читал, что Гвидо ван Россум сильно жалел, что разрешил и табы, и пробелы. Не вполне похоже на вшитый стандарт кода.
А вот автоформаттеры давно были, вроде ещё в досовские времена.
Нету у python аналога «go fmt». Не знаю, кто первый это придумал, но Go — единственный популярный язык, где это приходит из коробки. Хотя в IDE для Java это появилось раньше, но там — это часть среды, оно в комплект компилятора не входит.
Для C/C++ есть clang-format. Мне тоже часто не нравится то, что он делает, но если альтернатива — хаос или долгие разборки на тему «а нужно тут ставить два пробела или один?», то… ну его нафиг. Что clang-format сделал — то и будет. Точка.
Для C/C++ есть clang-format. Мне тоже часто не нравится то, что он делает, но если альтернатива — хаос или долгие разборки на тему «а нужно тут ставить два пробела или один?», то… ну его нафиг. Что clang-format сделал — то и будет. Точка.
Так PEP8 можно считать таким стандартом. Понятно, что он не тако жёсткий и даже там есть где немного срезать углы, но на работе у меня в редакторе по сохранению стоит выполнение autopep8 с конфигом, о котором договорились. Вот тебе и стандарт, вот тебе и автоматическое форматирование.
Если добавить к этому .editorconfig, то жить становится совсем просто.
Для Rust из коробки есть cargo fmt.
Кстати да! И тоже касается goimports — порядок импортов, их разбиение на блоки тоже определено стандартными инструментами.
Более строго было, пожалуй, только во времена Pascal и его родственников.
После PHP, где хотя и есть несколько стандартов, но их далеко не везде придерживаются, любой стандарт — это благо. Особенно если не нужен никакой тимлид, принуждающий ему следовать. Стандарт оформления кода — это тоже часть языка, на мой взгляд.
Более строго было, пожалуй, только во времена Pascal и его родственников.
После PHP, где хотя и есть несколько стандартов, но их далеко не везде придерживаются, любой стандарт — это благо. Особенно если не нужен никакой тимлид, принуждающий ему следовать. Стандарт оформления кода — это тоже часть языка, на мой взгляд.
Вместо того, чтобы слепо следовать указаниям непонятного супер-программиста Марка (который тоже может ошибаться), я предпочитаю заставлять всех своих программистов следовать стандартам кодирования, разработанными не самыми мелкими и уважаемыми организациями. Так больше вероятность, что выработанные ими стандарты логичны. Например 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
А есть ли в паблике стандарты Майкрософта? Наверняка же у них есть корпоративные правила, вот бы посмотреть. Интересует C#, в частности.
В 60% компаний где я работал применялся R# default.
Здесь достаточно интересная история. Она начинается в 2008 году, когда было объявлено о публикации StyleCop, инструменте, используемом в MS для проверки соответствия их стандартом. Инструмент до сих пор используется — StyleCop Analyzers, и список правил (не особо оформленный правда, причину см. ниже) доступен на сайте: https://stylecop.pdelvo.com/
Но в 2015 году, возможно из-за внутренних пертурбаций, стандарты поменялись — Automatic code formatter released to GitHub. Основное отличие, на которое все жалуются — это использование подчеркивания вместо «this.», как это было рекомендовано StyleCop. Тем не менее, на текущий момент рекомендуется использовать именно эти новые стандарты кодирования. Учтите, что это внутренние стандарты, Microsoft не публиковало каких-либо официальных стандартов для внешнего использования, так что используете эти инструменты на свое усмотрение.
Но в 2015 году, возможно из-за внутренних пертурбаций, стандарты поменялись — Automatic code formatter released to GitHub. Основное отличие, на которое все жалуются — это использование подчеркивания вместо «this.», как это было рекомендовано StyleCop. Тем не менее, на текущий момент рекомендуется использовать именно эти новые стандарты кодирования. Учтите, что это внутренние стандарты, Microsoft не публиковало каких-либо официальных стандартов для внешнего использования, так что используете эти инструменты на свое усмотрение.
Собственно, вот.
Есть еще Design Guidelines for Class Library Developers, которые зачастую берутся за основу для coding conventions на крупных проектах.
Есть еще Design Guidelines for Class Library Developers, которые зачастую берутся за основу для coding conventions на крупных проектах.
Стиль программирования определяется менталитетом программиста. Некоторые неплохие программеры не могут следовать стандартам, у них начинается внутренний конфликт который поглощает все их внимание, что резко сказывается на работе.
В таких случаях иногда идут дальше и в команде появляется человек ответственный за унификацию кода и документации.
А вообще без стандартизации в командной работе никуда.
В таких случаях иногда идут дальше и в команде появляется человек ответственный за унификацию кода и документации.
А вообще без стандартизации в командной работе никуда.
Самая большая проблема, с которой я сталкивался в командной работе — это «у нас так принято». Ничего не выбешивает больше, чем подобные заявляения.
Ребята, если вы хотите, чтобы я не использовал локальные переменные типа «host_pointer_to_locked_guest_structure_xxx», то напишите, блин, об этом где-нибудь. Если у вас есть соглашения о том как должны называться геттеры/сеттеры, то об этом необходимо написать в стайл-гайде.
Не разводите сектанство! У нас, конечно, свобода вероисповедания, но… в нерабочее время, пожалуйста!
P.S. Особенно доставляет когда в ответ на эту просьбу я слышу «ну, у нас и так большой стайл-гайд, мы не хотим его засорять мелочами». Либо это для вас неважно, «мелочи» — и тогда не стоит на это жаловаться на каждом code review, либо важно — и тогда пусть в стайл-гайде будет 1000 страниц. Выискивать вот эти вот «у нас так принято» постепенно узнавая у гуру «а как у нас принято» — куда сложнее, чем прочитать самый объемный style guide!
Ребята, если вы хотите, чтобы я не использовал локальные переменные типа «host_pointer_to_locked_guest_structure_xxx», то напишите, блин, об этом где-нибудь. Если у вас есть соглашения о том как должны называться геттеры/сеттеры, то об этом необходимо написать в стайл-гайде.
Не разводите сектанство! У нас, конечно, свобода вероисповедания, но… в нерабочее время, пожалуйста!
P.S. Особенно доставляет когда в ответ на эту просьбу я слышу «ну, у нас и так большой стайл-гайд, мы не хотим его засорять мелочами». Либо это для вас неважно, «мелочи» — и тогда не стоит на это жаловаться на каждом code review, либо важно — и тогда пусть в стайл-гайде будет 1000 страниц. Выискивать вот эти вот «у нас так принято» постепенно узнавая у гуру «а как у нас принято» — куда сложнее, чем прочитать самый объемный style guide!
А вы этот гайд на 100 страниц читать будете? На ревью, конечно, приятнее получить ссылку на документ, чем простое "у нас так принято", но легче не станет, мне кажется.
Сам я за жесткие автоматические проверки на стадии CI. Зачем спорить о том, что могут проверить машины?
А вы этот гайд на 100 страниц читать будете?Да, буду. Могу, конечно, что-то и забыть, но в любом случае это гораздо лучше чем попытки выяснить — это точно так принято или, может быть, только прихоть ревьюера, и что вообще этим делать.
На ревью, конечно, приятнее получить ссылку на документ, чем простое «у нас так принято», но легче не станет, мне кажется.Станет. Потому что если это мало-мальски вразумительный гайд, то там будет хотя бы формулировка того, «что у нас принято».
И, главное, это позволяет отделить «у нас так принято» от «мне так нравится». Моя задача, в общем-то не состоит в том, чтобы ублажать ревьюера. А с «у нас так принято» зачастую подавляющее большинство замечаний невозможно даже описать человеческим языком.
Тут есть одна тонкость: скорее всего «у нас так принято» это сокращенная версия «это консистентно остальному коду проекта». Всегда поражался людям которые модифицируя кода ленятся посмотреть на стиль используемый буквально в двух строках выше. Грубый пример — стайлгайд позволяет ставить звездочку как с пробелом после типа, так и без, весь код проекта использует один из вариантов, а некто берет и использует другой.
Всегда поражался людям которые модифицируя кода ленятся посмотреть на стиль используемый буквально в двух строках выше.А в двух строках ниже? А в соседнем файле? Мне статанализ проводить перед тем изменение на две строчки написать?
Тут есть одна тонкость: скорее всего «у нас так принято» это сокращенная версия «это консистентно остальному коду проекта».Точно-точно? И нигде других вариантов нету? Ну так впишите это в стайл гайд. Или есть и вы не хотите с этим заморачиваться? Ну а тогда почему я должен?
Грубый пример — стайлгайд позволяет ставить звездочку как с пробелом после типа, так и без, весь код проекта использует один из вариантов, а некто берет и использует другой.Именно. Это — как раз пример, который выбешивает меня, да: если в стайлгайде разрешили почему-то оба варианта, то зачем-то они ведь это сделали?
Если clang-format поправит (а он это любит) — ну Ok, но если нет — то причём тут я?
Ну у нас вот говорится, что консистетность первыше всего :) По поводу анализа — не доводите до абсурда. Обычно достаточно пары строк из того же файла. А дальше по индукции все будет консистентно.
Ну у нас вот говорится, что консистетность первыше всего :)Что интересно — я исхожу из ровно тех же соображений. И меня, кстати, поддерживают, создатели нашего стайл-гайда.
Если вы вводите какие-то правила «у нас так принято» в команде, то ваш кода становится неконсистентным по отношению ко всей компании!
Потому если хотите изменять правила — в соответствующий список рассылки!
Этот гайд импортируется в IDE и спокойно поддерживается, и не надо 1000 страниц читать.
Я бы сказал что этот стиль очень тяжело поддерживать руками. Но если ему научить clang-format… Почему нет? Лаконично и достаточно удобно — при условии, что можно быть уверенным что все точки с запятой и фигурные скобки соответствуют отступам.
Ага, попробуй clang-format научить такому. Он твои паспортные данные автоматически пошлёт в ближайшую псих-больницу.
На самом деле, если не хочешь видеть точки с запятой и фигурные скобки, то можно просто в редакторе задать для них цвет, который почти не отличается от фона. Такой подход отлично работает, например, в Лиспе, где скобок дофига и больше.
<sarcasm>Кто-то болен питоном)</sarcasm>
Вот все говорят: «фильм для дураков, для дураков». А мне понравилось! (с)
Как же я понимаю автора! Тема весьма и весьма актуальна для командной разработки. Больше всего добивает ситуация, когда в команду приходит новый разработчик и говорит: «Мне пофиг на ваш codestyle, я привык писать в стиле Керниган и Ричи». И начинается очередной локальный холивар.
Да пусть пишет хоть в стиле зелёной обезьяны, но что прописано в правилах — должно быть исполнено.
Если окажется что даже после этого его код вы не воспринимаете — ну добавьте пару новых пунктов в список.
Это как раз не страшно, страшно когда приходишь — а как писать тебе не говорят, говорят «ну тут же всё очевидно», а потом программа в 10 строк обсуждается неделю, потому что в ней нарушены 100500 неписанных правил.
Правила должны быть писанными — это облегчает жизнь всем.
Если окажется что даже после этого его код вы не воспринимаете — ну добавьте пару новых пунктов в список.
Это как раз не страшно, страшно когда приходишь — а как писать тебе не говорят, говорят «ну тут же всё очевидно», а потом программа в 10 строк обсуждается неделю, потому что в ней нарушены 100500 неписанных правил.
Правила должны быть писанными — это облегчает жизнь всем.
А вот я и сейчас вынужден следовать стандартам похожим на стандарты того Марка. Проекту несколько десятилетий, древний язык программирования. Есть толмуд по этим кем-то придуманным стандартам. Вплодь до того, сколько пробелов должно быть перед каждой командой, с какого столбца должны начинаться комментарии и так далее… Но это все можно понять — программисты приходят и уходят, а проект на Cobol вечен! Пришёл новый программист, прочитал доку по стандартам и пишет. Следующему будет всё ясно. Заказчиков можно понять. Или хаос или тупые стандарты...
Стандарты на отступы были обусловлены применением перфокарт.
Цитата из вики (про FORTRAN IV):
Структура программ изначально была ориентирована на ввод с перфокарт и имела ряд удобных именно для этого случая свойств. Так, с 1-й по 5-ю колонку располагалась область меток, 6-я служила для маркировки текста как продолжения предыдущей строки (любым символом, кроме пробела и «0»), а с 7-й по 72-ю располагался собственно текст оператора или комментария. Колонки с 73-й по 80-ю могли служить для нумерации карт (чтобы восстановить случайно рассыпавшуюся колоду) или для краткого комментария, транслятором они игнорировались.
Табулятор трактовался как 4 пробела. 1 пробел как разделитель, второй пробел как продолжение оператора. Итого=6. Можно конечно и 6 пробелов «настучать»…
Среды программирования на VAX-ах были. Тут автор «загнул». Например EVE чего стоит (включал в себя TPU) и кстати, в VMS жив по сей день…
Цитата из вики (про FORTRAN IV):
Структура программ изначально была ориентирована на ввод с перфокарт и имела ряд удобных именно для этого случая свойств. Так, с 1-й по 5-ю колонку располагалась область меток, 6-я служила для маркировки текста как продолжения предыдущей строки (любым символом, кроме пробела и «0»), а с 7-й по 72-ю располагался собственно текст оператора или комментария. Колонки с 73-й по 80-ю могли служить для нумерации карт (чтобы восстановить случайно рассыпавшуюся колоду) или для краткого комментария, транслятором они игнорировались.
Табулятор трактовался как 4 пробела. 1 пробел как разделитель, второй пробел как продолжение оператора. Итого=6. Можно конечно и 6 пробелов «настучать»…
Среды программирования на VAX-ах были. Тут автор «загнул». Например EVE чего стоит (включал в себя TPU) и кстати, в VMS жив по сей день…
На одной из работ был большой проект на С89, которому на тот момент было около 20 лет. Вопрос решался просто — написали скрипт для vi, который форматировал код.
А не проще один раз написать автоматический форматтер кода и пусть каждый пишет как ему нравится, в мастер ветке все равно будет единый формат?
Когда стайлгайд энфорсится человеком, это выглядит как насилие и произвол. Когда стайлгайд энфорсится хуком в гите, реджектящим пуш, это выглядит как часть условностей софта, к которым привыкаешь.
Все эти гайды — фигня полная. В моей практике, гайдами всегда все недовольны, кроме самих писателей гайдов. Поэтому в компании, где я сейчас работаю, я сделал так:
- есть всего несколько жестких правил: no tabs, line ending
- хороший код важнее хорошо отформатированного кода
- на ревью, я всем советую обращать внимание на то, что код делает, а не сколько пробелов в операторе if
- я написал, clang-format конфиг, который позволяет отформатировать код приличным образом
- если кому-то хочется гайда, он просто берет этот конфиг и форматирует свой код автоматически
- если кто вообще пофигист и пишет, как курица лапой, то я сам прогоняю его код через clang-format, даже не спрашивая
- ему всё равно пофиг, поэтому конфликтов на этой почве не возникает
- не было ещё ни одного спора по поводу этого гайда, потому что гайда как такового почти и нет
Нифига же себе «у нас нет гайда»! Полстраны на описание того, чего нет. И главное в вашем гайде — это таки clang-format.
У нас довольно большой гайд, но удивительным образом баталий на тему важных вещей (правил использования
У нас довольно большой гайд, но удивительным образом баталий на тему важных вещей (правил использования
auto, к примеру) — всегда было не так много. А вот по поводу отступов… bikeshedding, как он есть… Clang-format эту проблему успешно решает.
Не заметил в обсуждении, два важных факта:
1. Код — собственность компании. В интересах компании сделать программистов взаимозаменяемыми. Отсюда и общее владение кодом, когда любой может залезть и исправить любой кусок и стайлгайд. Компания решила применять стайлгайд — придется следовать. Тут нет месту холиварам.
2. Многие программисты немного аутисты. Они чувствуют себя лучше когда строго следуют определенному набору правил. И наоборот, если что-то не так, настроение у них портится сильно больше, чем того заслуживает неправильный отступ или перенос.
Марк из статьи похоже был конктетным аутистом. Но в коллективе из аутистов любые правила, лучше их отсутствия.
1. Код — собственность компании. В интересах компании сделать программистов взаимозаменяемыми. Отсюда и общее владение кодом, когда любой может залезть и исправить любой кусок и стайлгайд. Компания решила применять стайлгайд — придется следовать. Тут нет месту холиварам.
2. Многие программисты немного аутисты. Они чувствуют себя лучше когда строго следуют определенному набору правил. И наоборот, если что-то не так, настроение у них портится сильно больше, чем того заслуживает неправильный отступ или перенос.
Марк из статьи похоже был конктетным аутистом. Но в коллективе из аутистов любые правила, лучше их отсутствия.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История об ужасах стандартов кодирования