Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).
В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?
Что бывает в случае плохого результата code review?
Здравствуйте, RussianFellow, Вы писали:
RF>Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).
RF>В чём заключается code review?
Повышение качества кода, недопуск в код откровенно плохих практик и вообще всяких "левых" вещей.
Часто другие находят в коде то, что ты сам считаешь вполне нормальным и пропускаешь мимо.
RF>Есть ли у вас на работе такое и как часто, каким образом оно проводится?
Мы работаем по gitlab: при вливании боковика в транк (мастер) создается merge request и его смотрят
все участники проекта (порядка 10 человек). Там же, в gitlab пишутся комментарии, создаются дискуссии.
Ошибки исправляются и т.д., после чего ветка вливается. Сейчас в отдельной группе мы дополнительно
делаем ревью перед самой первой отправкой проекта в отдел тестирования, а также в отдельных других случаях.
RF>Кто проводит у вас code review?
Все, кто работает над проектом.
RF>Что бывает в случае плохого результата code review?
Код не принимается. Или ты его переписываешь, или ветка не вливается.
Вот буквально вчера мой код забраковали из-за того, что там была глобальная функция
Здравствуйте, RussianFellow, Вы писали:
RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review? RF>Что бывает в случае плохого результата code review?
Code review заключается в том, что прежде, чем написанный (или измененный) код попадет в проект, другой человек его просматривает на предмет ошибок, неудачных решений, соответствия принятому стилю и т.п.
В принципе, code review нацелен на улучшение качества кода. Свое г-но, как известно, не пахнет, и в своем коде человек склонен не замечать каких-то недостатков, которые с легкостью заметит другой человек.
Если код не проходит code review, он направляется на переделку, а потом опять на code review — и так до тех пор, пока код его не пройдет и не попадет в основную кодовую базу.
RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review? RF>Что бывает в случае плохого результата code review?
0. Есть
1. Чтение кода.
2. Провожу я.
3. Код возвращается на переделку.
Я читаю все коды всех студентов по всем лабам...
И нещадно возвращаю по 5-7-10 раз, пока не напишут, как следует...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, RussianFellow, Вы писали:
RF>Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).
Зачем?
RF>В чём заключается code review?
Тебя в поисковиках забанили? По запросу находится вагон релевантной информации.
RF>Есть ли у вас на работе такое и как часто, каким образом оно проводится?
Есть. При попытке комита в подветки, на которых стоит требование ревью, оно создается автоматом. Либо автор кода может сам его попросить, указав в комите специальный маркер.
RF>Кто проводит у вас code review?
Кто-то из группы/групп, которым принадлежит код, в который происходит комит.
RF>Что бывает в случае плохого результата code review?
Исправление кода до тех пор, пока он не пройдет ревью. В редких случаях комит просто выбрасывается в мусор (например, когда оказывается, что от него вреда будет больше, чем пользы).
Здравствуйте, RussianFellow, Вы писали:
RF>Уважаемые коллеги, предлагаю вам обсудить $SUBJECT_NAME RF>В чём заключается $SUBJECT_NAME? Есть ли у вас на работе $SUBJECT_NAME и $MORE_QUESTIONS?
Ну как бы только совсем с тобой не знакомые на такое должны клевать.
Когда я учился в институте, у нас не было никакого code review. И на нынешней и на всех предыдущих работах у меня не было никакого code review.
Главное--чтобы код работал и работал правильно.
RF>Когда я учился в институте, у нас не было никакого code review. И на нынешней и на всех предыдущих работах у меня не было никакого code review. RF>Главное--чтобы код работал и работал правильно.
Это — неправильно!
Как тогда учить студентов хорошему стилю и рефакторингу?
Для рефакторинга вариантов лаб не напасешься.
А тут тебе и коде ревью, и рефакторинг в одном флаконе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Vlad_SP, Вы писали:
V_S>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?
Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?
Здравствуйте, RussianFellow, Вы писали:
RF>Главное--чтобы код работал и работал правильно.
Один товарищ так же говорит.
Это не правильно!
Поймите, что абсолютную работоспособность кода вы никогда не докажете. Это значило бы полный перебор всех кейсов на входе.
Отсюда следует, что любой код — условно работоспособен. Т.е. проверен на ограниченом кол-ве тестов. Отсюда второй вывод — код постоянно под риском исправлений.
Как прикажете исправлять код который плохо написан?
Поэтому "лижбы работало" не годится. Должно И работало И красиво и понятно написано.
Для достижения второго пункта и делается кодревью.
Здравствуйте, kaa.python,
KP>Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?
Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.
Кодревью (а может, более точное название — code inspection) предназначен прежде всего для поиска, предупреждения и устранения ошибок. У нас в команде, например, любой может проинспектировать код хотя бы и тимлида, и ничего ему за это не будет Стиль вообще не обсуждается и не правится — поскольку стиль определен в Coding convention, и все программисты ему следуют, без труда читая и модифицируя код друг друга. А дизайн на кодревью тоже не обсуждается и не правится — поскольку этапу(-ам) кодревью еще предшествует этап design review, на котором как раз и выявляются и выправляются косяки в дизайне.
LVV>>Как тогда учить студентов хорошему стилю и рефакторингу? V_S>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?
"Мастерство не пропьешь"(с)...
Около 50 лет опыта, прочитано литературы едва ли не больше всех в России. Причем не только по С++, а все остальное по всем программистским вопросам...
Да и коды не такие объемные — лабы и курсовые.
В таких объемах указать студенту на его ОЧЕВИДНЫЕ ошибки — не очень большая проблема.
Я один могу преподавать всю программерскую и математическую часть учебного плана.
Не возьмусь читать английский, и гуманитарные дисциплины.
Хотя психологию — могу...
Как-то так.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, RussianFellow, Вы писали:
RF>Главное--чтобы код работал и работал правильно.
И еще, он должен быть человеку понятен, потому, что никому не нужен код, который невозможно развивать и поддерживать, даже если в данный момент кажется, что он работает правильно.
И вот для достижения этих целей используются разные инструменты. Code review — один из них.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.
Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.
Здравствуйте, Vlad_SP, Вы писали:
V_S>У нас в команде, например, любой может проинспектировать код хотя бы и тимлида, и ничего ему за это не будет
-- Василий Иванович, а правда, что я на партсобрании могу и тебя критиковать, и Фурманова, и мне за это ничего не будет?
-- Да, Петька. Ничего тебе за это не будет. Ни отпуска, ни увольнительных, ни папахи новой... Ничего тебе, Петька, не будет.
LVV>>Как тогда учить студентов хорошему стилю RF>У каждого программиста--свой стиль. Главное, чтобы код был читаемый.
Нет. Есть общие признаки хорошего стиля.
Читайте классиков: МакКоннелл, Саттер+Александреску. LVV>>Для рефакторинга вариантов лаб не напасешься. RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.
Значит вы не делали нескольких версий программы.
В нынешних реалиях рефакторинг делать приходится по-любому.
Более того, в матрице программиста 2 умение рефакторить является одним из обязательных скиллов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, RussianFellow, Вы писали:
RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.
Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
занимались бы безостановочно, без выходных и проходных. Начиная с азов: с правил именования сущностей, с декомпозиции данных, с декомпозиции функций и т.д. А у совсем невменяемых, таких как я, вы бы и до испытательного срока не дошли.
S>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Vlad_SP, Вы писали:
V_S>>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.
Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов.
Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle.
Здравствуйте, Sheridan, Вы писали:
Pzz>>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. S>Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle.
Компилятор и не следит, следит отдельная утилита. Компилятору, по большому счету, все равно, а вот любой IDE навязывает стиль, причем один и тот же. Это раздражает первые два дня, а потом понимаешь, что это правильно.
Что до школоты, это вряд ли. Ключевые люди там, в основном, все взрослые и уже отметившиеся в более других общеизвестных проектах (некоторые из этих проектов, впрочем, нонешняя школота может и не упомнить).
Здравствуйте, RussianFellow, Вы писали:
RF>В чём заключается code review? RF>Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?
Показываешь код своему товарищу. Он определяет, понятно ли написано.
RF>Что бывает в случае плохого результата code review?
Переписываешь так, чтобы было понятно.
Обычно это приводит к переименованию переменных и методов, и написанию комментов.
Сам алгоритм меняется редко.
Очень полезная штука. Особенно если приходится в свой код лезть где-то через полгода.
Здравствуйте, RussianFellow, Вы писали:
RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review? RF>Что бывает в случае плохого результата code review?
Суть code review проводимого в некоторых фирмах, в которых я больше не работаю, заключалась в том, чтоб самому быть на коне, а остальных, соответственно, мокать в дерьмо через закручивание твоих ревью в 20 итераций (в итоге у тебя работа стоит, а у них движется). Когда уже всё просмотрено 19 раз, то на 20-й что-то новое выясняется. В итоге ты свою работу делать не можешь, потому, что ревью будет посмотрено в лучшем случае раз в сутки, и то если менеджер пнет. Выясняется, конечно, что ты, например, точку в комментариях не поставил, что комментарии написаны не так как хотелось бы ревьювяшему, что код отформатирован не так, что названо что-то не так и в таком роде. Т.е. речь не о качестве кода, не о нахождении багов. В той же фирме работали и нормальные люди, которые реально ревьювили и находили ошибки, и не занимались втыканием палок в колеса, так что есть с чем сравнить.
В нормальной ситуации ревьювящие должны тоже отвечать за результат выполнения работ, которые они ревьювят (в частности и по срокам, и по результату), иначе приводит к ситуации описанной выше. Да, были ещё товарищи которые чётко следовали указаниям и ни с чем не спорили, в итоге у них ревью проходило, но получается картина, когда тебе рассказали как написать код, ты написал, его заревьювили закоммитили -- не работает, а кто виноват, понятно, не тот кто ценные советы раздавал. Опять же ввиду отсутствия ответственности, ревьювящие занимались просто другой частью проекта.
Вообще суть code review состоит в том, чтобы:
* обнаружить потенциальные ошибки и другие проблемные ситуации в коде;
* оценить хоть как-то архитектурную правильность решения (если, конечно, это видно из кода, часто нет);
* проверить наличие шапок с копирайтами, следование кодстайлу и т.п.
По-моему мнению в нормальной организации к ревью должны привлекаться только люди кровно заинтересованные в продвижении именно этой части проекта в нужную сторону, у ревью должны быть чёткие сроки, например, у каждого должна быть _обязанность_ ежедневно смотреть ревью. Потом чтоб исключить закручивание ревью в 20 итераций должно быть принято правило, что код просматривается один раз и выписываются все замечания. Замечания исправляются или нет, но на очередной итерации в ранее просмотренном коде не должно обнаруживаться что-то новое. Если есть какие-то вопросы, то не нужно устраивать переписку в ревью, а решить их лично, через телефон и т.п., потому, что переписка в ревью опять же вызывает новую итерацию, на которую могут уйти следующие сутки.
И замечания в ревью должны быть обоснованные. "Переделай здесь вот так-то" -- это не замечание. Должно быть обоснование, почему. В противном случае эту работу лучше отдать товарищу имеющему особое мнение, почему здесь должно быть так-то, ибо получается что рассказывает как нужно делать один, а ответственность за результат останется на другом. Ошибки, некачественный код, неправильные архитектурные решения -- такие должны быть замечания, а не рассуждения на тему "как бы сделал я". У кода есть автор, который за него отвечает и он сделал как он сделал, и это не должно обсуждаться. Стоит указывать на принципиальные недостатки, а не устраивать обсуждение кода.
Зачастую, особенно когда уже есть целая цепочка ревью или отдельная ветка следовало бы как-то документировать работу и я бы советовал писать подробное описание в мерж-коммите (что сделано в целом, в этой ветке, не в деталях, а обощенно, чтоб за деревьями можно было увидеть лес: иначе часто код понятен, а зачем такая масса изменений -- нет). Это имеет отношение к пониманию архитектуры, само архитектурное решение возможно стоит где-то в комментария может, описать на человеческом языке.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Как тогда учить студентов хорошему стилю RF>>У каждого программиста--свой стиль. Главное, чтобы код был читаемый. LVV>Нет. Есть общие признаки хорошего стиля. LVV>Читайте классиков: МакКоннелл, Саттер+Александреску.
С этим трудно поспорить, безусловно общие признаки хорошего стиля есть. Вопрос в их трактовке. И вопрос вообще не технический, не про C++.
Проблема в отсутствии формальных и чётких критериев, что такое хорошо, и что такое плохо. Они субъективны. Вот если бы законы так принимались, это бы работало? Я думаю очевидно, что нет.
И, допустим, рассмотрим работу типичной софтовой фирмы. Где нанято сколько-то программистов и раз в полгода-год действует система награждения хороших и выгоняния плохих (смысл, конечно, не в выгонянии "плохих", реально плохих мало, а в ротации кадров через найм новых более дешёвых сотрудников и в удерживании действительно хороших сотрудников через премирование, например). Это делается так или иначе через KPI реализованный в том или ином виде. Называться оно может какими угодно словами, но в конечном счёте в зачёт пойдут оценки руководителей и/или менеджеров проектов по результатам сделанной работы с их, менеджерской, точки зрения. А с менеджерской точки зрения важны решённые баги, сделанные релизы, достижение поставленных целей. Красивость и качество кода принципиального значения не имеет до тех пор, пока качество кода удовлетворяет с менеджерской точки зрения (проект сделан, багов нет, сроки не затянуты, претензий от заказчика нет).
И вот теперь теперь нехитрая задачка, как оказаться на вершине пирамиды KPI? Для этого совершенно не обязательно выдавать фантастические результаты, более того -- вредно. Проект кончится, что дальше неизвестно. Ну какой автомеханик сделает так, чтоб вы к нему не вернулись ещё раз? Так же и здесь. Но ведь тебя будут сравнивать с другими, выпишут в список, отсортируют по какому-то критерию, голову списка наградят, хвост отрежут. Как оказаться наверху пирамицды, а не в нижнем слое? Кроме очевидной стратегии продираться наверх из последних сил есть более простая: пинками сгонять остальных вниз. Более того, если ты находишься уже близко к вершине или на вершине пирамиды, то выше головы уже не прыгнуть и эта стратегия, сталкивать остальных вниз, остаётся _единственной_. Вроде бы вещь очевидная для тех кто должен уметь управлять людьми.
А в случае субъективных критериев оценки, сама возможность оценки для находящегося на вершине пирамиды становится прекрасным инструментом _отрицательного_ _отбора_. Вниз будут ехать все кто может потенциально вытолкнуть поколебать сложившуюся пирамиду и подниматься те, кто сам съедет при первой возможности.
Вот и вся суть грамотного code review. И она ПЕРВИЧНА. Да кого интересует мифическое качество кода? Нормальных людей интересуют регулярные поступления денежных средств в карман. А там -- пирамида описанная выше. То, что в подчинённые нужно вытягивать полных дураков я вообще не от программистов услышал, примерно в таком же ключе рассуждений. Не надо думать, что у программистов будет по-другому.
Конечно, если пирамиду сделать безразмерной, бесконечно высокой, то проблема уходит тоже куда-то в бесконечность. Но как правило пирамидка маленькая и над ней стеклянный потолок. А за ним менеджеры и директора.
Все ли участники команды согласны с тем, что code review приносит выгоду?
Оправдываются трудозатраты на проведение CR и на исправления по результатам CR? Не бывает ли так, что ради соблюдения, какого-либо принципа проектирования, на котором кто-нибудь настаивает, код в итоге значительно усложняется, срываются сроки, падает производительность, мотивация, настроение? На мой взгляд, зрелость разработчика заключает не в знании и фанатичном соблюдении всех принципов проектирования, а знании где и когда эти принципы нужно соблюсти любой ценой, а где можно|лучше не соблюдать.
Не сопровождается ли CR взаимные уступками (я лояльно отношусь к твоему коды, а ты к моему) или, наоборот, местью (ты ко мне придерешься, я к тебе буду придраться).
Есть ли член команды с правом решающего голоса?
Кто обладает правом "вето"?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Все ли участники команды согласны с тем, что code review приносит выгоду?
Не могу сказать за всех, но вроде бы у нас внедрению CR никто особо не сопротивлялся.
IB>Оправдываются трудозатраты на проведение CR и на исправления по результатам CR?
Субъективно:
У нас ревью занимает обычно от получаса до нескольких часов. Иногда вылавливаются довольно тонкие дефекты. Если бы такие
дефекты уходили вместе с версией на тест, их бы обнаруживали в лучшем случае через несколько дней, а то и позже,
когда версия уйдет в релиз. Это не допустимо. Потратить час-два несколько раз в месяц — это достаточно небольшая
плата за CR, я считаю. К тому же есть стажеры и вообще люди, которые в проекте недавно, за ними нужен усиленный
контроль, без CR здесь никуда.
IB>Не бывает ли так, что ради соблюдения, какого-либо принципа проектирования, на котором кто-нибудь настаивает, IB>код в итоге значительно усложняется, срываются сроки, падает производительность, мотивация, настроение?
Не припомню такого. Мы относимся к CR без фанатизма, должен где-то быть баланс между качеством кода (которое можно улучшать до
бесконечности, но в какие сроки и какой ценой?) и поставкой запланированных фич клиентам. Для бизнеса важнее второе, это все понимают.
IB>На мой взгляд, зрелость разработчика заключает не в знании и фанатичном соблюдении всех принципов проектирования, а знании где и когда эти принципы нужно соблюсти любой ценой, а где можно|лучше не соблюдать.
У нас CR — это не стремление любой ценой привести код к 100% идеалу, выбросив без сожаления все, что не
попадает под это определение, а просто некий процесс коллективной оценки кода с целью недопущения явных дефектов и
откровенно плохих практик.
IB>Не сопровождается ли CR взаимные уступками (я лояльно отношусь к твоему коды, а ты к моему) или, наоборот, местью (ты ко мне придерешься, я к тебе буду придраться).
Местью — точно нет
По поводу уступок... Есть старые кодовые базы, которые "просто работают". Код там, мягко говоря, не очень.
И они тоже принимаются. Главное, чтобы новый код не содержал откровенных дефектов.
IB>Есть ли член команды с правом решающего голоса? IB>Кто обладает правом "вето"?
В общем случае, замечания участников равноценны. Если возникают споры — вмешиваются начальники отделов и тогда
решаем: "вливать", "не вливать" или "влить, но позже исправить".
Здравствуйте, so5team, Вы писали:
RF>>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.
S>Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
занимались бы безостановочно, без выходных и проходных. Начиная с азов: с правил именования сущностей, с декомпозиции данных, с декомпозиции функций и т.д.
Скорее, такой код никогда не попал бы в репозиторий, так что до рефакторинга просто не дошло бы.
S>А у совсем невменяемых, таких как я, вы бы и до испытательного срока не дошли.
У вполне вменяемых тоже не дошел бы, скорее всего.
P.S. А ТС случаем не жирный тролль? Что-то не верится с существование программиста с таким незамутненным сознанием.
Здравствуйте, CreatorCray, Вы писали:
RF>>Уважаемые коллеги, предлагаю вам обсудить $SUBJECT_NAME RF>>В чём заключается $SUBJECT_NAME? Есть ли у вас на работе $SUBJECT_NAME и $MORE_QUESTIONS?
На PHP пишешь?
CC>Ну как бы только совсем с тобой не знакомые на такое должны клевать.
Здравствуйте, Lexey, Вы писали:
L>P.S. А ТС случаем не жирный тролль?
Были такие подозрения пока на какие-то его вопросы в профильных форумах по C++ не наткнулся.
L>Что-то не верится с существование программиста с таким незамутненным сознанием.
Доводилось видеть отдельных похожих "специалистов". Но в бюджетных или околобюджетных НИИ. Возможно, в каких-то заштатных ВУЗах таких же можно отыскать в штучных экземплярах.
fk0> Вот и вся суть грамотного code review. И она ПЕРВИЧНА. Да кого интересует мифическое качество кода? Нормальных людей интересуют регулярные поступления денежных средств в карман. А там -- пирамида описанная выше. То, что в подчинённые нужно вытягивать полных дураков я вообще не от программистов услышал, примерно в таком же ключе рассуждений. Не надо думать, что у программистов будет по-другому.
У нас денежный стимул отсутствует.
Поэтому впереди — то самое мифическое качество кода.
И напомню, что есть книжка от Микрософт "Инфраструктура программных проектов".
Тоже неплохие рекомендации прописаны.
А также есть книжка Джуста Виссера "Разработка обслуживаемых программ на языке С#".
И такая же от него по Java.
Там вполне конкретные рекомендации.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
S>>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Здравствуйте, so5team, Вы писали:
S>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
mgu>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить.
Опять же — читайте классиков!
Писал Дейкстра, писал Кнут.
Но статьи старые, в русском инете не найти. Может быть, есть в английском.
Основная мысль состоит в том, что такой код (напичканный goto)
а) трудно читать
б) трудно модифицировать.
Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход.
Это значительно упрощает как чтение, так и модификацию.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
mgu>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить. LVV>Опять же — читайте классиков! LVV>Писал Дейкстра, писал Кнут.
Что бы они ни писали, не нужно их считать безусловными авторитетами претендующими на абсолютное знание.
LVV>Основная мысль состоит в том, что такой код (напичканный goto) LVV>а) трудно читать LVV>б) трудно модифицировать.
Но for, while -- тоже замаскированные goto. А switch-case в C/C++ вообще страшная вещь в контексте того, что case можно вставлять в середину какого-либо другого цикла или даже ветви if'а. Если развивать мысль в этом направлении дальше, то циклы стоит запретить и всё делать через рекурсию. Разговоры вокруг и около goto сводятся к поговорке "заставь дурака богу молиться..."
Однако практически за 50 лет goto так и не пропал, как и longjmp, как и switch-case. В них есть смысл. Разумеется не для изоморфного переноса блок-схемы алгоритма в функцию языка программирования, как делают некоторые студенты.
LVV>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход. LVV>Это значительно упрощает как чтение, так и модификацию.
Не соглашусь в общем случае. Практически может быть удобно иметь выходы из функции в случае ошибок немедленно, чем устраивать 10-кратной вложенности if'ы только ради того, чтоб иметь единственный return в конце. Последний вариант как раз трудно читать и трудно модифицировать.
Да и вдалбливаемая студентам мысль, на счёт программы как _последовательности_ инструкций она как бы несколько порочна. Проблему как раз заложили первопроходцы структурного программирования в языках типа фортран, паскаль и т.п. Где вместо понятия вычисляемого выражения появилось понятие последовательности инструкций вместо вычисляемого выражения. В C/C++ теперь есть и то и другое, например в выражении "return x ? y : z" сколько выходов? Если ветви по которым может пойти вычисление две.
LVV>>Писал Дейкстра, писал Кнут. fk0> Что бы они ни писали, не нужно их считать безусловными авторитетами претендующими на абсолютное знание.
В данном случае конкретно статья Кнута была не мнением, а исследованием.
Вывод Кнута (на основании исследований кода программ на фортране) однозначен: использование goto без должной дисциплины приводит к большему количеству ошибок.
Это — НАУЧНЫЙ результат. LVV>>Основная мысль состоит в том, что такой код (напичканный goto) LVV>>а) трудно читать LVV>>б) трудно модифицировать. fk0> Но for, while -- тоже замаскированные goto. А switch-case в C/C++ вообще страшная вещь в контексте того, что case можно вставлять в середину какого-либо другого цикла или даже ветви if'а. Если развивать мысль в этом направлении дальше, то циклы стоит запретить и всё делать через рекурсию. Разговоры вокруг и около goto сводятся к поговорке "заставь дурака богу молиться..."
Ни for, ни while не являются замаскированными goto.
А переключатель вообще-то в парадигму структурного программирования не входит...
Рекурсия — наше все в функциональных языках. Имеет место быть отсутствие goto обычно в таких языках (хотя мож где и есть, но я сомневаюсь).
Насчет дураков.
По известной формуле:
10% программеров всегда делают "правильно", 10% программеров — всегда "дураки", 80% — то так, то эдак.
Этим -то как раз прописанные правила и нужны.
Это как в библии: 10% людей выполняют заповеди всегда (даже при отсутствии прописанных заповедей), 10% — не выполняют никогда, а 80% — как написан, для них заповеди и писали.
Или как в шахматах.
Всегда начинающим говорят: конь на краю доски — плохо.
Но гроссмейстеры частенько так играют. Потому как они — гроссмейстеры. Те самые первые 10%. fk0> Однако практически за 50 лет goto так и не пропал, как и longjmp, как и switch-case. В них есть смысл. Разумеется не для изоморфного переноса блок-схемы алгоритма в функцию языка программирования, как делают некоторые студенты.
Есть — для гроссмейстеров. Но не для начинающих неофитов. LVV>>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход. LVV>>Это значительно упрощает как чтение, так и модификацию. fk0> Не соглашусь в общем случае. Практически может быть удобно иметь выходы из функции в случае ошибок немедленно, чем устраивать 10-кратной вложенности if'ы только ради того, чтоб иметь единственный return в конце. Последний вариант как раз трудно читать и трудно модифицировать.
Для выхода из функции немедленно есть исключения.
Их и назвали по-другому, чтобы различать легитимные вычисления и нелегитимные. fk0> Да и вдалбливаемая студентам мысль, на счёт программы как _последовательности_ инструкций она как бы несколько порочна. Проблему как раз заложили первопроходцы структурного программирования в языках типа фортран, паскаль и т.п. Где вместо понятия вычисляемого выражения появилось понятие последовательности инструкций вместо вычисляемого выражения. В C/C++ теперь есть и то и другое, например в выражении "return x ? y : z" сколько выходов? Если ветви по которым может пойти вычисление две.
Выход — ОДИН! Возвращаются разные значения — это да.
Чтобы было 2 выхода, должно быть два return.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Pzz, Вы писали:
Pzz>Компилятор и не следит, следит отдельная утилита. Компилятору, по большому счету, все равно, а вот любой IDE навязывает стиль, причем один и тот же. Это раздражает первые два дня, а потом понимаешь, что это правильно.
Да? Ну попробуй в другом редакторе написать и скомпилировать потом.
Pzz>Что до школоты, это вряд ли. Ключевые люди там, в основном, все взрослые и уже отметившиеся в более других общеизвестных проектах (некоторые из этих проектов, впрочем, нонешняя школота может и не упомнить).
Тем не менее это сраные уроды.
Здравствуйте, LaptevVV, Вы писали:
VV>>>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход. LVV>>>Это значительно упрощает как чтение, так и модификацию. fk0>> Не соглашусь в общем случае. Практически может быть удобно иметь выходы из функции в случае ошибок немедленно, чем устраивать 10-кратной вложенности if'ы только ради того, чтоб иметь единственный return в конце. Последний вариант как раз трудно читать и трудно модифицировать. LVV>Для выхода из функции немедленно есть исключения. LVV>Их и назвали по-другому, чтобы различать легитимные вычисления и нелегитимные.
Ох нет. Исключения не предназначены для того, чтобы участвовать в нормальном потоке управления, они -- для исключительных ситуаций, ошибок. Это не выход из функции, это longjmp. Большой и тяжелый. И ещё где-то на стороне -- сохранённый контекст, чтоб было куда возвращаться. И возврат в совершенно другое место (вот где "два выхода").
Я хотел показать, что выражение такого вида:
return a ? b : c ? d : e ? f : g
эквиэвалентны следующему:
if (a) return b;
if (c) return d;
if (e) return f;
return g;
Где как раз виднеются "множественные выходы из функции". И ничего плохого в них нет. Иначе следовало бы признать первое выражение порочным.
А попытка такой код записать "с одним выходом" часто кончается многоуровневыми вложенными if-блоками, в которых точно легко запутаться. Это наверное должнно быть очевидно. Такой код точно "трудно читаемый" и всё прочее. Не дай бог там где-то ещё и else -- ошибки практически гарантированы.
fk0>> Да и вдалбливаемая студентам мысль, на счёт программы как _последовательности_ инструкций она как бы несколько порочна. Проблему как раз заложили первопроходцы структурного программирования в языках типа фортран, паскаль и т.п. Где вместо понятия вычисляемого выражения появилось понятие последовательности инструкций вместо вычисляемого выражения. В C/C++ теперь есть и то и другое, например в выражении "return x ? y : z" сколько выходов? Если ветви по которым может пойти вычисление две. LVV>Выход — ОДИН! Возвращаются разные значения — это да. LVV>Чтобы было 2 выхода, должно быть два return.
Проблема в наличии словосочетания "выход" из функции. Выхода как такового не существует. Выход -- это то чему присваивается регистр PC после собственно выхода и он уж точно всегда один (а в случае "выхода по исключению" оно запросто может оказаться совсем другой точкой в программе). Если не воспринимать программу как последовательность инструкций (то, что нужно выжечь калёным железом и запретить такое словосочетание, для студентов в первую очередь), а как набор логических правил позволяющих выполнить вычисления, то вопрос о количестве выходов из функции даже встать не может. Нет у функции такой сущности как выход. Функция -- это способ отобразить множество значений аргументов на другое множество выходных значений. Не нужно думать, что процессор будет программу последовательно по строчкам выполнять. С современными компиляторами порядок давно может оказаться очень странным. Важно лишь какое правило применяется. И не важно сверху-вниз, снизу-вверх или ещё как записана программа.
И смысла считать количество операторов return в функции, кроме слепого следования безумной идее, мол "выход должен быть один" нет. Равно как тщательности в избегании goto и прочих "вредных практик". Вредные они только в отдельных очумелых ручках, но не следует из этого распространять некие мифические правила правильного программирования на всю отрасль. Серебряной пули нет. В практических языках программирования не просто просто так есть return (можно было бы сделать как в octave/matlab, через присвоение переменной, и убрать return), не зря есть goto или break с параметром или last с меткой. 40-50 лет уже есть и конца не видно. И только в "учебных" ЯВУ встречаются какие-то дикости, вроде запрета goto. Если инструмент позволяет выстрелить себе в ногу, то не обязательно этой возможностью следует воспользоваться. А если эту возможность отобрать, то получится детская игрушка не пригодная для практических задач, где таки стрелять нужно уметь, и иногда даже в ногу.
Эти практики вызывали ошибки в фортране? Это не goto плох, а его использование. В gcc два десятилетия есть computed goto и switch в обычном C/C++ ещё больше есть. Не слышно о серьёзно пострадавших. Не нужно подменять понятия. goto достаточно хорош для обычного программирования и только в особо неопытных руках может применяться каким-то диким образом. Но это не значит что goto плохой, или его не следует использовать. Его лишь нужно УМЕТЬ использовать.
Можно сделать return и забыть что-то, например мьютекс, на выходе из функции? Не нужны костыли в виде единственного return (о чем легко забыть и никто не проверит), а нужно либо завернуть основную часть функции в отдельную функцию (лямбду, локальный класс), или использовать в C++ локальные инстансы объектов с соответствующим деструктором. Вот хорошая практика, а единственный return -- костыль, причём плохой.
Здравствуйте, LaptevVV, Вы писали:
mgu>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить. LVV>Опять же — читайте классиков! LVV>Писал Дейкстра, писал Кнут. LVV>Но статьи старые, в русском инете не найти. Может быть, есть в английском.
Ну, классики много чего говорили. И про богоугодность каскадной разработки, и про 640 килобайт памяти, и про важность гномиков на интервью.
LVV>Основная мысль состоит в том, что такой код (напичканный goto) LVV>а) трудно читать LVV>б) трудно модифицировать. LVV>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход.
Меня терзают смутные сомнения, что return -- это замаскированный goto.
LVV>Это значительно упрощает как чтение, так и модификацию.
С таким подходом бывает, что код заносит вправо за область видимости монитора.
Кстати, "ОДИН выход" уже несколько лет как подвергли анафеме. Ещё недавно в обязательный номер цирковой программы на интервью входило прочитать "catch наш" в правильном порядке. А нынче во все стороны кидаются исключениями, событиями и задержками.
А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься.
А ещё есть yield -- это вообще проходной двор.
Здравствуйте, RussianFellow, Вы писали:
RF>Когда я учился в институте, у нас не было никакого code review. И на нынешней и на всех предыдущих работах у меня не было никакого code review. RF>Главное--чтобы код работал и работал правильно.
Судя по всему, что ты тут пишешь — у вас за ревью прораб отвечает, он же сапогами и пинает непрошедших его прораб-ревью
Здравствуйте, kaa.python, Вы писали:
V_S>>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?
KP>Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?
Может тем, что он сам никогда не проходил никаких код-ревью?
Здравствуйте, Vlad_SP, Вы писали:
KP>>Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?
V_S>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.
За оформление кода в стиле KnR пожизненный эцих с гвоздями
Здравствуйте, Pzz, Вы писали:
V_S>>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.
Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.
Это что, в Го как Пайтоне? Или это просто какой-то "правильный" редактор следит, но в общем случае пох?
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Как тогда учить студентов хорошему стилю и рефакторингу? V_S>>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит? LVV>"Мастерство не пропьешь"(с)... LVV>Около 50 лет опыта, прочитано литературы едва ли не больше всех в России.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Как тогда учить студентов хорошему стилю RF>>У каждого программиста--свой стиль. Главное, чтобы код был читаемый. LVV>Нет. Есть общие признаки хорошего стиля. LVV>Читайте классиков: МакКоннелл, Саттер+Александреску.
Вот Александреску как пример для подражания так себе
Здравствуйте, LaptevVV, Вы писали:
mgu>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить. LVV>Опять же — читайте классиков!
Для плюсов готу ломает автоматику управления локальными объектами, не?
LVV>>Нет. Есть общие признаки хорошего стиля. LVV>>Читайте классиков: МакКоннелл, Саттер+Александреску. M>Вот Александреску как пример для подражания так себе
Я — про общую их книжку по стилю программирования на С++.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>"Мастерство не пропьешь"(с)... LVV>>Около 50 лет опыта, прочитано литературы едва ли не больше всех в России. M>Это серьёзная заявка
А то...
Но, конечно, чтобы читать какой-то курс — надо к нему готовиться полгода.
В свое время, лет 20 назад, наш тогдашний завкаф сказала: Лаптева клонировать надо.
Что ни спросишь — он знает, в каких книжках и что прочитать...
А вообще-то после разработки и написания бортовой оси — что может быть непонятного в программировании?
Вопрос только во времени — готовиться надо.
Самое сложное — лабы продумать и написать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
mgu>>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить. LVV>>Опять же — читайте классиков! LVV>>Писал Дейкстра, писал Кнут. LVV>>Но статьи старые, в русском инете не найти. Может быть, есть в английском. mgu>Ну, классики много чего говорили. И про богоугодность каскадной разработки, и про 640 килобайт памяти, и про важность гномиков на интервью.
Ну, это не классики...
... mgu>Кстати, "ОДИН выход" уже несколько лет как подвергли анафеме. Ещё недавно в обязательный номер цирковой программы на интервью входило прочитать "catch наш" в правильном порядке. А нынче во все стороны кидаются исключениями, событиями и задержками.
Ну, пишите, как хотите. Структурное программирование — это только рекомендации... mgu>А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься.
А это вообще не язык программирования mgu>А ещё есть yield -- это вообще проходной двор.
Это в питоне, что ли?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Нет. Есть общие признаки хорошего стиля. LVV>>>Читайте классиков: МакКоннелл, Саттер+Александреску. M>>Вот Александреску как пример для подражания так себе LVV>Я — про общую их книжку по стилю программирования на С++.
Это про "Стандарты прогрпммарования на C++" Герб Саттер, Андрей Александреску?
Если так, то это великолепная книга. Авторы всё очень толково изложили.
Здравствуйте, mgu, Вы писали:
mgu>Меня терзают смутные сомнения, что return -- это замаскированный goto.
Нет, это НЕ замаскированный goto!
Ключевое отличие return — переход НЕ ПО МЕТКЕ, а по сохраненному в стеке адресу возврата.
Это позволяет передавать управление не на фиксированную точку, а именно туда, откуда был вызов.
Мы выделили четыре пункта, которые должны быть в обновленном код-ревью:
1. Проверка архитектуры решения. Довольно очевидная вещь. Ожидаем это от старших разработчиков с экспертизой в данном компоненте.
2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте.
3. Передача знаний, которая заключается в изучении бизнес-логики и кодовой базы новичками и джунами посредством код-ревью.
4. Возможность оценки hard skills разработчиков. Хочется, чтобы за каждым разработчиком был закреплен наставник, который оценивает рост, определяет вектор развития, подмечает какие-то недостатки, делает замечания и так далее. Поэтому наставник также должен видеть код своих подопечных.
Возможно, кто-то видит другие цели или не согласен с нашими — делитесь в комментариях. А я пока перейду от формулирования целей к поиску средств их достижения – мы решили, что хотим достичь их все и (почти) сразу.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Marty, Вы писали:
mgu>>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить. LVV>>Опять же — читайте классиков!
M>Для плюсов готу ломает автоматику управления локальными объектами, не?
Компиляторы сейчас за этим следят, но для POD типов можно такого наколбасить...
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, LaptevVV, Вы писали:
LVV>2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте.
Экспертиза бывает судебно-медицинская, например. А здесь должно быть написано "являющихся экспертами" или "имеющих опыт работы". Двоечники, блин! Мидлы!
Здравствуйте, mgu, Вы писали:
S>>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Здравствуйте, Эйнсток Файр, Вы писали:
LB>> Вот мы и нашли виновника проблем в космической отрасли
ЭФ>Но ты сделал для российской космической области меньше, чем он, ЭФ>поэтому ты больше виновник. Предлагаю тебя расстрелять забанить.
Я сделал больше, ведь я нашел виновника. Меня надо поощрить. А тебя предлагаю на всякий случай расстрелять забанить.
Здравствуйте, Lazy Bear, Вы писали:
LB>Я сделал больше, ведь я нашел виновника. Меня надо поощрить. А тебя предлагаю на всякий случай расстрелять забанить.
Зачем сразу банить? Можно на ревью кода от Русского Парня посадить. Пожизненно.
Здравствуйте, LaptevVV, Вы писали:
LVV>"Мастерство не пропьешь"(с)...
Оно, конечно, так. Но иногда некоторые коллеги присылают мне жалобы: такой-то участок кода не работает. Я открываю. Первая реакция: какой идиот это написал? Чуть позже с глаз спадает пелена, и я вижу: код — мой. Сделан так, что строка, добавленная коллегой, его сломала. Видимо, писался в спешке. А может, сейчас требования изменились. Деталей не помню, код написан несколько лет назад. И приходится мне правки в него вносить самому.
Конечно, это не типичный случай. Но всякой бываеь.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Писал Дейкстра, писал Кнут. fk0>> Что бы они ни писали, не нужно их считать безусловными авторитетами претендующими на абсолютное знание. LVV>В данном случае конкретно статья Кнута была не мнением, а исследованием.
Нет таких исследований.
LVV>Вывод Кнута (на основании исследований кода программ на фортране) однозначен: использование goto без должной дисциплины приводит к большему количеству ошибок.
Нет.
Использование goto для прыжков назад приводит к увеличению ошибок. Использование goto для прыжков вперёд количество ошибок уменьшает. Это было проверено уже много раз в проектах, которые пишутся на С.
Но по какой-то идиотской причине до университетов это до сих пор не дошло. Видимо, из-за того, что преподаватели практическим программированием занимаются мало.
Здравствуйте, LaptevVV, Вы писали:
fk0>> Но for, while -- тоже замаскированные goto. А switch-case в C/C++ вообще страшная вещь в контексте того, что case можно вставлять в середину какого-либо другого цикла или даже ветви if'а. Если развивать мысль в этом направлении дальше, то циклы стоит запретить и всё делать через рекурсию. Разговоры вокруг и около goto сводятся к поговорке "заставь дурака богу молиться..." LVV>Ни for, ни while не являются замаскированными goto.
Да ну? А если дизассемблером посмотреть?
LVV>>"Мастерство не пропьешь"(с)... P>Оно, конечно, так. Но иногда некоторые коллеги присылают мне жалобы: такой-то участок кода не работает. Я открываю. Первая реакция: какой идиот это написал? Чуть позже с глаз спадает пелена, и я вижу: код — мой. Сделан так, что строка, добавленная коллегой, его сломала. Видимо, писался в спешке. А может, сейчас требования изменились. Деталей не помню, код написан несколько лет назад. И приходится мне правки в него вносить самому. P>Конечно, это не типичный случай. Но всякой бываеь.
Бывает. Я для этого применяю ТОТАЛЬНЫЙ коммент.
Студенты не верят, что я могу открыть прогу 7-летней давности и все по ней рассказать.
Когда видят комменты — глаза на лоб лезут: комментов больше кода...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>В данном случае конкретно статья Кнута была не мнением, а исследованием. C>Нет таких исследований.
Найду ссыль — пришлю. LVV>>Вывод Кнута (на основании исследований кода программ на фортране) однозначен: использование goto без должной дисциплины приводит к большему количеству ошибок. C>Нет. C>Использование goto для прыжков назад приводит к увеличению ошибок. Использование goto для прыжков вперёд количество ошибок уменьшает. Это было проверено уже много раз в проектах, которые пишутся на С.
Это было задолго до С — еще для фортрана. И как раз Кнутом. C>Но по какой-то идиотской причине до университетов это до сих пор не дошло. Видимо, из-за того, что преподаватели практическим программированием занимаются мало.
Если до американских не дошло, то это ИХ проблемы...
У нас — все дошло.
Пишем вообще без goto...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Вывод Кнута (на основании исследований кода программ на фортране) однозначен: использование goto без должной дисциплины приводит к большему количеству ошибок. LVV>Это — НАУЧНЫЙ результат. LVV>>>Основная мысль состоит в том, что такой код (напичканный goto) LVV>>>а) трудно читать LVV>>>б) трудно модифицировать.
А как ты в Фотране 4 сделаешь цикл типа while без goto вверх?
Можно использовать обычный цикл do, но там нужно переменную цикла модифицировать где-то по ходу действия. Такой код гораздо менее понятен, чем просто goto вверх.
Ну, еще можно использовать арифметический if. В нем слова goto нет, не так раздражает. Я постоянно так делал.
Да, я знаю, что Фортран 4 для новых проектов не используется. Но за десятиления на нем накопилась масса работающего кода. Его используют.
А goto вниз — это вполне нормально. В Java break не метку не просто так придумали. Выход из кучи вложенных циклов, освобождение ресурсов в C, да мало ли.
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, пишите, как хотите. Структурное программирование — это только рекомендации...
Увидел словосочетание "структурное программирование" и вспомнил случай из прошлого. Я о нем уже как-то рассказывал, ЕМНИП.
Зашел я как-то в одну контору к приятелям по какому-то поводу. А у нах какая-то ерунда с компом приключилась. Деталей не помню. Только предложил я им попробовать натравить на эту ерунду утилитку, которую я сделал несколькими днями раньше. Делов на несколько сотен строк.
Запустили ее. Вижу, работает.
И увидел я там одного препода не то информатики, не то программирования. Адепт структурного программирования. Я шапочно был с ним знаком. И что-то он кому-то задвигал о вреде goto. И рассказывал азбучные истины структурного программирования. А я возьми и покази ему на комп, где моё творение работало. Вот в той программе, говорю, есть один goto, который экономит строки кода и облегчает отладку. Препода бомбануло, "я бы тебе зачет не поставил", все дела. Но коллеги пиво поставили мне за вовремя принесенную программу, а не ему за отстаивание принципов структурного программирования.
Позже выяснилось: этот препод не знал, что номера строк в Васике давно отменили. Но это уже другая история.
Здравствуйте, LaptevVV, Вы писали:
LVV>Бывает. Я для этого применяю ТОТАЛЬНЫЙ коммент. LVV>Студенты не верят, что я могу открыть прогу 7-летней давности и все по ней рассказать. LVV>Когда видят комменты — глаза на лоб лезут: комментов больше кода...
Я сейчас редко оставляю в коде комментарии. Обычно они нужны, когда требуется не забыть что-нибудь допилить. После допиливания комментарии убираются. Время 2-х и 6-символьных идентификаторов прошло.
Иногда комментировал чужой код, написанный в стиле Фортрана 4. Но это для себя, когда копать приходилось. Некоторые умудрялись писать такой код даже на FoxPro, в котором goto по записям, а не по коду, бегает.
Здравствуйте, Pzz, Вы писали:
Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.
В С++ IDE уже умеют форматировать код по мере набора с помощью clang-format (не только отступы, а именно продвинутое форматирование: скобочки, пробелы, перенос строк и т.п.). Стиль какой хочешь можно определить.
Здравствуйте, Sheridan, Вы писали:
S>Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle.
Нормальные утилиты на компиляторе и основаны: clang-format. Просто по ключевым словам С++ полноценно не отформатируешь.
P>Я сейчас редко оставляю в коде комментарии. Обычно они нужны, когда требуется не забыть что-нибудь допилить. После допиливания комментарии убираются. Время 2-х и 6-символьных идентификаторов прошло.
У меня была другая картина.
Научник использовал научные обозначения величин, принятые во всем мире и прописанные во всех статьях...
И настоятельно мне рекомендовал использовать эти имена для соответствующих переменных.
Ибо я когда-нить перестану у него работать, а ему потом разбираться...
Вот и приходилось однобуквенные имена комментариями обкладывать. P>Иногда комментировал чужой код, написанный в стиле Фортрана 4. Но это для себя, когда копать приходилось. Некоторые умудрялись писать такой код даже на FoxPro, в котором goto по записям, а не по коду, бегает.
Я вот прямо сейчас код курсовой одного студня правлю.
Сижу, комменты добавляю — чтобы понятней ему тоже было...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>>>Писал Дейкстра, писал Кнут. fk0>>> Что бы они ни писали, не нужно их считать безусловными авторитетами претендующими на абсолютное знание. LVV>>В данном случае конкретно статья Кнута была не мнением, а исследованием. C>Нет таких исследований.
Если есть возможность, найди вот эту статью Кнута: An empirical study of FORTRAN programs
У него еще есть на тему структурного программирования с goto. https://web.archive.org/web/20130731202547/http:/pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>И настоятельно мне рекомендовал использовать эти имена для соответствующих переменных. LVV>Ибо я когда-нить перестану у него работать, а ему потом разбираться... LVV>Вот и приходилось однобуквенные имена комментариями обкладывать.
Это был суровый матан?
У математиков давно принята система именования идентификаторов. Наверное, она в каждом коллективе своя. Но имена типа FP12K2 никого не смущали. В 6 символов математики умудрялись заложить глубокий смысл. Они и сейчас так пишут.
А почему односимвольные имена? Даже в "Искре-226" допускались двухсимвольные. Второй символ обязательно цифра. Вот это был клинический случай. Приходилось специальный документ, описывающий идентификаторы, составлять. Потому что программа с комментариями могла в память не уместиться.
LVV>Я вот прямо сейчас код курсовой одного студня правлю. LVV>Сижу, комменты добавляю — чтобы понятней ему тоже было...
Так вставь ему пистон на ближайшей проработке. Ведь скажет же потом: это не я, это препод мне посоветовал так писать.
LVV>>2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте. LB>Экспертиза бывает судебно-медицинская, например. А здесь должно быть написано "являющихся экспертами" или "имеющих опыт работы". Двоечники, блин! Мидлы!
Да пора привыкнуть к этому карго-культу, уже везде эту прямую кальку используют любители показаться важными и идущими в ногу с.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>"Мастерство не пропьешь"(с)... P>>Оно, конечно, так. Но иногда некоторые коллеги присылают мне жалобы: такой-то участок кода не работает. Я открываю. Первая реакция: какой идиот это написал? Чуть позже с глаз спадает пелена, и я вижу: код — мой. Сделан так, что строка, добавленная коллегой, его сломала. Видимо, писался в спешке. А может, сейчас требования изменились. Деталей не помню, код написан несколько лет назад. И приходится мне правки в него вносить самому. P>>Конечно, это не типичный случай. Но всякой бываеь. LVV>Бывает. Я для этого применяю ТОТАЛЬНЫЙ коммент. LVV>Студенты не верят, что я могу открыть прогу 7-летней давности и все по ней рассказать. LVV>Когда видят комменты — глаза на лоб лезут: комментов больше кода...
Почитайте Фаулера.
"...comments often are used as a deodorant. It’s surprising how often you look at thickly commented code and notice that the comments are there because the code is bad."
"When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous."
Здравствуйте, Skorodum, Вы писали:
S>>Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle. S>Нормальные утилиты на компиляторе и основаны: clang-format. Просто по ключевым словам С++ полноценно не отформатируешь.
Ключевое: "на основе". Не часть компилятора, а отдельная утилита. На секундочку, настраиваемая.
А не так как у goвноавторов — стиль прибит гвоздями к компилятору.
Здравствуйте, Skorodum, Вы писали:
Pzz>>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста. S>В С++ IDE уже умеют форматировать код по мере набора с помощью clang-format (не только отступы, а именно продвинутое форматирование: скобочки, пробелы, перенос строк и т.п.). Стиль какой хочешь можно определить.
Здравствуйте, LaptevVV, Вы писали:
C>>Нет таких исследований. LVV>Если есть возможность, найди вот эту статью Кнута: An empirical study of FORTRAN programs LVV>У него еще есть на тему структурного программирования с goto. LVV>https://web.archive.org/web/20130731202547/http:/pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
Это не исследование. Кроме того, там не разделяется goto назад и goto вперёд. Они фундаментально отличаются.
Здравствуйте, RussianFellow, Вы писали:
RF>Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).
Так как я пишу без ошибок, то делать Code review моего кода всем быстро надоедает. Последний code review свёлся к переписываю кода из стиля Круговая оборона к стилю Контрактное программирование. Это произошло из-за того, что меня заранее не предупредили в каком стиле писать код.
Когда же я делаю code review, то обычно ищу (и нахожу) фактические ошибки, не выловленные при тестировании, к полному неудовольствию начальника проекта. Так как я работаю иностранным консультантом, то приходится проявляеть дипломатические способности и толерантно относиться ко многим нарушениям наилучших практик программирования. Например, если в спецификациях записано, что код должен соответсвововать MISRA C++, то найти список несоответствий довольно просто, однако практика показывает, что далеко не всегда после этого код будет исправлен, так как на работоспособность кода это не влияет.
Здравствуйте, LaptevVV, Вы писали:
C>>Использование goto для прыжков назад приводит к увеличению ошибок. Использование goto для прыжков вперёд количество ошибок уменьшает. Это было проверено уже много раз в проектах, которые пишутся на С. LVV>Это было задолго до С — еще для фортрана. И как раз Кнутом.
То что бред сказали ещё до С — меньше бредом не становится.
C>>Но по какой-то идиотской причине до университетов это до сих пор не дошло. Видимо, из-за того, что преподаватели практическим программированием занимаются мало. LVV>Если до американских не дошло, то это ИХ проблемы...
До американских дошло, что современная практика слегка отличается от 1960-го.
LVV>У нас — все дошло.
Ага, потому спутники и падают. Одна точка выхода из функции полёта — в Тихий океан.
LVV>Пишем вообще без goto...
Ну да, прививаете бредовые привычки с детства.
Здравствуйте, LaptevVV, Вы писали:
mgu>>А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься. LVV>А это вообще не язык программирования
Буква L как бы намекает. Просто синтаксис не си-подобный.
mgu>>А ещё есть yield -- это вообще проходной двор. LVV>Это в питоне, что ли?
Здравствуйте, std.denis, Вы писали:
LVV>>>2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте. LB>>Экспертиза бывает судебно-медицинская, например. А здесь должно быть написано "являющихся экспертами" или "имеющих опыт работы". Двоечники, блин! Мидлы!
SD>Да пора привыкнуть к этому карго-культу, уже везде эту прямую кальку используют любители показаться важными и идущими в ногу с.
Уже?
Но панталоны, фрак, жилет,
Всех этих слов на русском нет;
А вижу я, винюсь пред вами,
Что уж и так мой бедный слог
Пестреть гораздо б меньше мог
Иноплеменными словами,
mgu>>>А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься. LVV>>А это вообще не язык программирования mgu>Буква L как бы намекает. Просто синтаксис не си-подобный.
Буквы P нет... mgu>>>А ещё есть yield -- это вообще проходной двор. LVV>>Это в питоне, что ли? mgu>И там тоже.
И ЧО?
Структурное программирование касается внутренней организации кода в процедурах и функциях.
В однопроцессорной схеме.
B прекрасно себя показало и показывает.
Несмотря ни на какие yieldы...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
C>>>Нет таких исследований. LVV>>Если есть возможность, найди вот эту статью Кнута: An empirical study of FORTRAN programs LVV>>У него еще есть на тему структурного программирования с goto. LVV>>https://web.archive.org/web/20130731202547/http:/pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf C>Это не исследование. Кроме того, там не разделяется goto назад и goto вперёд. Они фундаментально отличаются.
Твое слово против слова Кнута.
Но у Дональда, по крайней мере, статья есть. А у тебя — нет.
Если есть — давай, почитаю.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Ну и напоследок: http://sci-hub.tw/10.1145/356635.356640 — это более поздняя статья от Кнута, где он пишет о том, что его опыт академического программирования не совсем применим к реальному миру. И что goto таки полезен, и приводит примеры этого (страница 287) и практически повторяет мои утверждения на стр. 294.
RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review? RF>Что бывает в случае плохого результата code review?
мне куда более интересно зачем нужен скрум, эджайл и канбан. а. еше 5с и абс забыл.
п.с. а кодревью штука полезная. зачастую новый работник может сгенерить код, исправляющий ошибку в одном блоке и из-за этого исправления рушится нахрен все остальное. и не из бандитских намерений, а просто потому, что он еще не знает как функционирует система в комплексе. тупо не знает бизнес процессы.
LVV>>Ни for, ни while не являются замаскированными goto. C>Да ну? А если дизассемблером посмотреть?
А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?
А давай еще разложим команды ассемблера на микрокоманды? Если уж спускаться внутрь — то спускаться до микросхем...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Ни for, ни while не являются замаскированными goto. C>>Да ну? А если дизассемблером посмотреть? LVV>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?
А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер.
Здравствуйте, Pzz, Вы писали:
Pzz>Ключевые люди там, в основном, все взрослые и уже отметившиеся в более других общеизвестных проектах
Угу, как раз из тех, что считают свой стиль единственно верным.
Здравствуйте, LaptevVV, Вы писали:
LVV>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?
Я не очень понимаю, зачем опускаться на уровень ассемблерных команд. Ты всегда, компилируя проект, создаешь и ассемблерные листинги. Чтобы почитать на досуге? Мне за всю жизнь пришлось их читать несколько раз. Править — никогда.
О командах. ЕМНИП, команды цикла и перехода в самом деле разные. Но команда цикла, которая loop, работает со счетчиком. Команды для цикла типа while я не помню. Обычно делается проверка условия, и по результатам либо безусловный переход вверх, либо условный вниз.
Совсем оффтоп. А зато jmp и ret, по сути, одно и то же. И call где-то там же.
LVV>>>>Ни for, ни while не являются замаскированными goto. C>>>Да ну? А если дизассемблером посмотреть? LVV>>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды? C>А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер.
Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды? C>>А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер. LVV>Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto
Как только начинаются вложенные циклы с выходом по флагу — goto предоставляет намного более высокий уровень.
LVV>>>>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды? C>>>А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер. LVV>>Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto C>Как только начинаются вложенные циклы с выходом по флагу — goto предоставляет намного более высокий уровень.
Для этого есть break — более высокого уровня в силу обязательного ограничения выхода вниз, а не в произвольное место.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto C>>Как только начинаются вложенные циклы с выходом по флагу — goto предоставляет намного более высокий уровень. LVV>Для этого есть break — более высокого уровня в силу обязательного ограничения выхода вниз, а не в произвольное место.
Выделено.
Здравствуйте, Pzz, Вы писали:
Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.
И этот стить конечно обоснован статистическими исследованиями?
...
А, нет. Стиль не обоснован. Ерунда, значит.
Здравствуйте, Pzz, Вы писали:
BFE>>И этот стить конечно обоснован статистическими исследованиями? Pzz>Ну, одним людям надо программы писать, а другим — стили обследовать...
Хороший стиль уменьшает количество багов и увеличивает производительность труда.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>И этот стить конечно обоснован статистическими исследованиями? Pzz>>Ну, одним людям надо программы писать, а другим — стили обследовать...
BFE>Хороший стиль уменьшает количество багов и увеличивает производительность труда.
Угу. Только при командной разработке все вынуждены использовать не свой личный стиль, а стиль, кем-то выбранный в качестве командного. А если все равно стиль в большинстве случаев выбирает кто-то, а не сам разработчик, то почему бы этим кем-то и не быть Робом Пайком? Его стиль не хуже любого другого, но при этом его использование снимает всякие дискуссии о стилях.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, RussianFellow, Вы писали:
RF>>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.
S>Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Lexey, Вы писали:
L>>P.S. А ТС случаем не жирный тролль? Что-то не верится с существование программиста с таким незамутненным сознанием.
BFE>Это далеко не худший образчик кода. Бывает много, много хуже...
Плюсую!
Имел дело как-то с кодом, в котором не было комментариев, не было пробелов, порядок расстановки строк не соблюдался, порядок расстановки фигурных скобок не соблюдался, на одной строке писалось по несколько действий--приходилось долго сидеть над этим кодом, чтобы понять, что же он делает.
Здравствуйте, RussianFellow, Вы писали:
RF>Здравствуйте, B0FEE664, Вы писали:
BFE>>Здравствуйте, Lexey, Вы писали:
L>>>P.S. А ТС случаем не жирный тролль? Что-то не верится с существование программиста с таким незамутненным сознанием.
BFE>>Это далеко не худший образчик кода. Бывает много, много хуже...
RF>Плюсую!
RF>Имел дело как-то с кодом, в котором не было комментариев, не было пробелов, порядок расстановки строк не соблюдался, порядок расстановки фигурных скобок не соблюдался, на одной строке писалось по несколько действий--приходилось долго сидеть над этим кодом, чтобы понять, что же он делает.
И в Visual Studio, и в Visual Studio Code есть автоматическое форматирование кода и даже есть комбинация клавиш для его запуска.
Здравствуйте, RussianFellow, Вы писали:
RF>Имел дело как-то с кодом, в котором не было комментариев, не было пробелов, порядок расстановки строк не соблюдался, порядок расстановки фигурных скобок не соблюдался, на одной строке писалось по несколько действий--приходилось долго сидеть над этим кодом, чтобы понять, что же он делает.
И это далеко не самое худшее. Хуже всего, когда в коде есть ошибки и при этом есть неявные зависимости в коде.
Здравствуйте, B0FEE664, Вы писали:
Pzz>> Его стиль не хуже любого другого, но при этом его использование снимает всякие дискуссии о стилях.
BFE>Я правильно понимаю, что согласно этому стилю открывающая скобка находится не в том же столбце, что и закрывающая?
Посмотри сам. Все программы на Go сформатированны одинаково
И да, меня самого этот стиль бесит. Вернее, бесил два дня. Потом я привык
Здравствуйте, Sheridan, Вы писали:
S>Ключевое: "на основе". Не часть компилятора, а отдельная утилита. На секундочку, настраиваемая. S>А не так как у goвноавторов — стиль прибит гвоздями к компилятору.
Здравствуйте, Эйнсток Файр, Вы писали:
LVV>>Я один могу преподавать всю программерскую и математическую часть учебного плана.
ЭФ>А процессор голыми руками в чистом поле из песка изготовить сможете, или нехватает практических навыков?
Россия — это вам не Калифорния и не Израиль. Тут земля черная, плодородная, нет полей из чистого песка.
Здравствуйте, LaptevVV, Вы писали:
LVV>Основная мысль состоит в том, что такой код (напичканный goto)
Ключевое слово тут "напичканный".
LVV>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход. LVV>Это значительно упрощает как чтение, так и модификацию.
Ты понимаешь, что ты сейчас выступил против исключений и return из середины функции? Впрочем, Дейкстра бы с тобой согласился
LVV>>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход. LVV>>Это значительно упрощает как чтение, так и модификацию. Pzz>Ты понимаешь, что ты сейчас выступил против исключений и return из середины функции? Впрочем, Дейкстра бы с тобой согласился
Да, мы с ним ОДНОЙ крови...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, RussianFellow, Вы писали:
RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.
Хотя бы за тем, чтобы бюджет проекта не проваливался.
1. Найти ошибку на стадии программирования (самим программистом) для проекта стоит мало.
2. Найти ошибку на стадии code review, стоит чуть дороже
3. Найти ошибку на стадии тестирования стоит еще дороже (ибо время тестера, потом время программиста и время code review)
4. Найти ошибку в продакшене может стоить очень много, плюс потеря доверия клиента.
Как пример у нас есть отдел, которые работает с аэропортами, так вот нашлась ошибка, к сожалению уже в продакшене, из-за которой в Дюссельдорфе а в аэропорту около 50 тыс чемоданов не выехали.
Аэропорт потом развозил эти чемоданы на такси, а счет выставил нашей конторе плюс всякую фигню еще. В общем ошибка обошлась конторе примерно в 100 тыс евро.
Попадись она на стадии ревью или тестирования затраты на ее устранение были бы ничтожно малы по сравнению с этой суммой.