Code review (просмотр кода)
От: RussianFellow Россия http://russianfellow.livejournal.com
Дата: 25.04.19 11:26
Оценка: -9 :))) :))) :)
Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).

В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?
Что бывает в случае плохого результата code review?
1613 г. = 2024 г.
Re: Code review (просмотр кода)
От: okman Беларусь https://searchinform.ru/
Дата: 25.04.19 11:58
Оценка: 14 (2) +3
Здравствуйте, RussianFellow, Вы писали:

RF>Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).


RF>В чём заключается code review?


Повышение качества кода, недопуск в код откровенно плохих практик и вообще всяких "левых" вещей.
Часто другие находят в коде то, что ты сам считаешь вполне нормальным и пропускаешь мимо.

RF>Есть ли у вас на работе такое и как часто, каким образом оно проводится?


Мы работаем по gitlab: при вливании боковика в транк (мастер) создается merge request и его смотрят
все участники проекта (порядка 10 человек). Там же, в gitlab пишутся комментарии, создаются дискуссии.
Ошибки исправляются и т.д., после чего ветка вливается. Сейчас в отдельной группе мы дополнительно
делаем ревью перед самой первой отправкой проекта в отдел тестирования, а также в отдельных других случаях.

RF>Кто проводит у вас code review?


Все, кто работает над проектом.

RF>Что бывает в случае плохого результата code review?


Код не принимается. Или ты его переписываешь, или ветка не вливается.
Вот буквально вчера мой код забраковали из-за того, что там была глобальная функция
Re: Code review (просмотр кода)
От: XOOIOOX  
Дата: 25.04.19 12:14
Оценка: -1 :))) :)
Здравствуйте, RussianFellow, Вы писали:

RF>Что бывает в случае плохого результата code review?


Ставят в угол, чтобы подумал над своим поведением.
Re: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 25.04.19 13:02
Оценка: +2
Здравствуйте, RussianFellow, Вы писали:

RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?

RF>Что бывает в случае плохого результата code review?

Code review заключается в том, что прежде, чем написанный (или измененный) код попадет в проект, другой человек его просматривает на предмет ошибок, неудачных решений, соответствия принятому стилю и т.п.

В принципе, code review нацелен на улучшение качества кода. Свое г-но, как известно, не пахнет, и в своем коде человек склонен не замечать каких-то недостатков, которые с легкостью заметит другой человек.

Если код не проходит code review, он направляется на переделку, а потом опять на code review — и так до тех пор, пока код его не пройдет и не попадет в основную кодовую базу.
Re: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 25.04.19 14:08
Оценка:
RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?
RF>Что бывает в случае плохого результата code review?
0. Есть
1. Чтение кода.
2. Провожу я.
3. Код возвращается на переделку.
Я читаю все коды всех студентов по всем лабам...
И нещадно возвращаю по 5-7-10 раз, пока не напишут, как следует...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Code review (просмотр кода)
От: Lexey Россия  
Дата: 25.04.19 14:59
Оценка: +1 -1
Здравствуйте, RussianFellow, Вы писали:

RF>Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).


Зачем?

RF>В чём заключается code review?


Тебя в поисковиках забанили? По запросу находится вагон релевантной информации.

RF>Есть ли у вас на работе такое и как часто, каким образом оно проводится?


Есть. При попытке комита в подветки, на которых стоит требование ревью, оно создается автоматом. Либо автор кода может сам его попросить, указав в комите специальный маркер.

RF>Кто проводит у вас code review?


Кто-то из группы/групп, которым принадлежит код, в который происходит комит.

RF>Что бывает в случае плохого результата code review?


Исправление кода до тех пор, пока он не пройдет ревью. В редких случаях комит просто выбрасывается в мусор (например, когда оказывается, что от него вреда будет больше, чем пользы).
"Будь достоин победы" (c) 8th Wizard's rule.
Re: Code review (просмотр кода)
От: CreatorCray  
Дата: 25.04.19 18:42
Оценка: 11 (4) +8 :))) :))) :))
Здравствуйте, RussianFellow, Вы писали:

RF>Уважаемые коллеги, предлагаю вам обсудить $SUBJECT_NAME

RF>В чём заключается $SUBJECT_NAME? Есть ли у вас на работе $SUBJECT_NAME и $MORE_QUESTIONS?

Ну как бы только совсем с тобой не знакомые на такое должны клевать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[2]: Code review (просмотр кода)
От: RussianFellow Россия http://russianfellow.livejournal.com
Дата: 25.04.19 19:12
Оценка: :))) :)
Когда я учился в институте, у нас не было никакого code review. И на нынешней и на всех предыдущих работах у меня не было никакого code review.
Главное--чтобы код работал и работал правильно.
1613 г. = 2024 г.
Проще показать
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 25.04.19 23:02
Оценка: 9 (1) +1 :))) :))) :))) :))) :)
Здравствуйте, RussianFellow, Вы писали:

RF> каким образом оно проводится?


Примерно вот так:

С уважением, Artem Korneev.
Отредактировано 25.04.2019 23:03 Artem Korneev . Предыдущая версия .
Re[3]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 26.04.19 03:10
Оценка:
RF>Когда я учился в институте, у нас не было никакого code review. И на нынешней и на всех предыдущих работах у меня не было никакого code review.
RF>Главное--чтобы код работал и работал правильно.
Это — неправильно!
Как тогда учить студентов хорошему стилю и рефакторингу?
Для рефакторинга вариантов лаб не напасешься.
А тут тебе и коде ревью, и рефакторинг в одном флаконе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Code review (просмотр кода)
От: Vlad_SP  
Дата: 26.04.19 07:16
Оценка: +3 -1
Здравствуйте, LaptevVV,

LVV>Как тогда учить студентов хорошему стилю и рефакторингу?


Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?
Re[5]: Code review (просмотр кода)
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 26.04.19 07:41
Оценка:
Здравствуйте, Vlad_SP, Вы писали:

V_S>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?


Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?
Re[3]: Code review (просмотр кода)
От: barn_czn  
Дата: 26.04.19 08:02
Оценка: +1
Здравствуйте, RussianFellow, Вы писали:

RF>Главное--чтобы код работал и работал правильно.


Один товарищ так же говорит.
Это не правильно!
Поймите, что абсолютную работоспособность кода вы никогда не докажете. Это значило бы полный перебор всех кейсов на входе.
Отсюда следует, что любой код — условно работоспособен. Т.е. проверен на ограниченом кол-ве тестов. Отсюда второй вывод — код постоянно под риском исправлений.
Как прикажете исправлять код который плохо написан?
Поэтому "лижбы работало" не годится. Должно И работало И красиво и понятно написано.

Для достижения второго пункта и делается кодревью.
Re[6]: Code review (просмотр кода)
От: Vlad_SP  
Дата: 26.04.19 08:15
Оценка: +2
Здравствуйте, kaa.python,

KP>Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?


Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.

Кодревью (а может, более точное название — code inspection) предназначен прежде всего для поиска, предупреждения и устранения ошибок. У нас в команде, например, любой может проинспектировать код хотя бы и тимлида, и ничего ему за это не будет Стиль вообще не обсуждается и не правится — поскольку стиль определен в Coding convention, и все программисты ему следуют, без труда читая и модифицируя код друг друга. А дизайн на кодревью тоже не обсуждается и не правится — поскольку этапу(-ам) кодревью еще предшествует этап design review, на котором как раз и выявляются и выправляются косяки в дизайне.
Re[5]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 26.04.19 08:24
Оценка:
LVV>>Как тогда учить студентов хорошему стилю и рефакторингу?
V_S>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?
"Мастерство не пропьешь"(с)...
Около 50 лет опыта, прочитано литературы едва ли не больше всех в России. Причем не только по С++, а все остальное по всем программистским вопросам...
Да и коды не такие объемные — лабы и курсовые.
В таких объемах указать студенту на его ОЧЕВИДНЫЕ ошибки — не очень большая проблема.

Я один могу преподавать всю программерскую и математическую часть учебного плана.
Не возьмусь читать английский, и гуманитарные дисциплины.
Хотя психологию — могу...
Как-то так.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.04.19 08:28
Оценка: +2
Здравствуйте, RussianFellow, Вы писали:

RF>Главное--чтобы код работал и работал правильно.


И еще, он должен быть человеку понятен, потому, что никому не нужен код, который невозможно развивать и поддерживать, даже если в данный момент кажется, что он работает правильно.

И вот для достижения этих целей используются разные инструменты. Code review — один из них.
Re[7]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.04.19 08:30
Оценка: +1 -2 :)
Здравствуйте, Vlad_SP, Вы писали:

V_S>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.


Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.
Re[7]: Code review (просмотр кода)
От: so5team https://stiffstream.com
Дата: 26.04.19 08:32
Оценка: :))
Здравствуйте, Vlad_SP, Вы писали:

V_S>У нас в команде, например, любой может проинспектировать код хотя бы и тимлида, и ничего ему за это не будет


-- Василий Иванович, а правда, что я на партсобрании могу и тебя критиковать, и Фурманова, и мне за это ничего не будет?
-- Да, Петька. Ничего тебе за это не будет. Ни отпуска, ни увольнительных, ни папахи новой... Ничего тебе, Петька, не будет.

Извините
Re[4]: Code review (просмотр кода)
От: RussianFellow Россия http://russianfellow.livejournal.com
Дата: 26.04.19 08:33
Оценка: :))) :))
Здравствуйте, LaptevVV, Вы писали:

LVV>Как тогда учить студентов хорошему стилю


У каждого программиста--свой стиль. Главное, чтобы код был читаемый.

LVV>Для рефакторинга вариантов лаб не напасешься.


Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.
1613 г. = 2024 г.
Re[5]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 26.04.19 08:45
Оценка: +2
LVV>>Как тогда учить студентов хорошему стилю
RF>У каждого программиста--свой стиль. Главное, чтобы код был читаемый.
Нет. Есть общие признаки хорошего стиля.
Читайте классиков: МакКоннелл, Саттер+Александреску.
LVV>>Для рефакторинга вариантов лаб не напасешься.
RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.
Значит вы не делали нескольких версий программы.
В нынешних реалиях рефакторинг делать приходится по-любому.
Более того, в матрице программиста 2 умение рефакторить является одним из обязательных скиллов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Code review (просмотр кода)
От: Bj777x Германия  
Дата: 26.04.19 08:54
Оценка: +4
RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.

Значит это всего лишь следующее: вы плохой программист и ваши программы на самом деле никому не нужны
„Nun gut, wer bist du denn?“ „Ein Teil von jener Kraft, Die stets das Böse will und stets das Gute schafft.“
Re[5]: Code review (просмотр кода)
От: so5team https://stiffstream.com
Дата: 26.04.19 08:56
Оценка: +2
Здравствуйте, RussianFellow, Вы писали:

RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.


Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно, без выходных и проходных. Начиная с азов: с правил именования сущностей, с декомпозиции данных, с декомпозиции функций и т.д. А у совсем невменяемых, таких как я, вы бы и до испытательного срока не дошли.
Re[6]: Code review (просмотр кода)
От: Bj777x Германия  
Дата: 26.04.19 09:03
Оценка:
S>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно, без


Етить колотить, там только goto не хватает доя полного комплекта
„Nun gut, wer bist du denn?“ „Ein Teil von jener Kraft, Die stets das Böse will und stets das Gute schafft.“
Re[6]: Code review (просмотр кода)
От: anton_t Россия  
Дата: 26.04.19 09:32
Оценка:
Здравствуйте, so5team, Вы писали:

S> подобных творений
Автор: RussianFellow
Дата: 11.04.19


Душераздирающее зрелище
Re[8]: Code review (просмотр кода)
От: Sheridan Россия  
Дата: 26.04.19 09:39
Оценка: :))
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Vlad_SP, Вы писали:


V_S>>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.


Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов.

Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle.
Matrix has you...
Re[7]: Code review (просмотр кода)
От: so5team https://stiffstream.com
Дата: 26.04.19 09:52
Оценка: +1
Здравствуйте, anton_t, Вы писали:

S>> подобных творений
Автор: RussianFellow
Дата: 11.04.19


_>Душераздирающее зрелище


"всю жизнь без всякого рефакторинга программировал" (c)
Re[9]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.04.19 10:02
Оценка:
Здравствуйте, Sheridan, Вы писали:

Pzz>>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов.

S>Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle.

Компилятор и не следит, следит отдельная утилита. Компилятору, по большому счету, все равно, а вот любой IDE навязывает стиль, причем один и тот же. Это раздражает первые два дня, а потом понимаешь, что это правильно.

Что до школоты, это вряд ли. Ключевые люди там, в основном, все взрослые и уже отметившиеся в более других общеизвестных проектах (некоторые из этих проектов, впрочем, нонешняя школота может и не упомнить).
Re: Code review (просмотр кода)
От: alpha21264 СССР  
Дата: 26.04.19 10:24
Оценка:
Здравствуйте, RussianFellow, Вы писали:

RF>В чём заключается code review?

RF>Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?

Показываешь код своему товарищу. Он определяет, понятно ли написано.

RF>Что бывает в случае плохого результата code review?


Переписываешь так, чтобы было понятно.
Обычно это приводит к переименованию переменных и методов, и написанию комментов.
Сам алгоритм меняется редко.

Очень полезная штука. Особенно если приходится в свой код лезть где-то через полгода.

Течёт вода Кубань-реки куда велят большевики.
Re: Code review (просмотр кода)
От: fk0 Россия https://fk0.name
Дата: 26.04.19 10:27
Оценка: +1
Здравствуйте, RussianFellow, Вы писали:

RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?

RF>Что бывает в случае плохого результата code review?

Суть code review проводимого в некоторых фирмах, в которых я больше не работаю, заключалась в том, чтоб самому быть на коне, а остальных, соответственно, мокать в дерьмо через закручивание твоих ревью в 20 итераций (в итоге у тебя работа стоит, а у них движется). Когда уже всё просмотрено 19 раз, то на 20-й что-то новое выясняется. В итоге ты свою работу делать не можешь, потому, что ревью будет посмотрено в лучшем случае раз в сутки, и то если менеджер пнет. Выясняется, конечно, что ты, например, точку в комментариях не поставил, что комментарии написаны не так как хотелось бы ревьювяшему, что код отформатирован не так, что названо что-то не так и в таком роде. Т.е. речь не о качестве кода, не о нахождении багов. В той же фирме работали и нормальные люди, которые реально ревьювили и находили ошибки, и не занимались втыканием палок в колеса, так что есть с чем сравнить.

В нормальной ситуации ревьювящие должны тоже отвечать за результат выполнения работ, которые они ревьювят (в частности и по срокам, и по результату), иначе приводит к ситуации описанной выше. Да, были ещё товарищи которые чётко следовали указаниям и ни с чем не спорили, в итоге у них ревью проходило, но получается картина, когда тебе рассказали как написать код, ты написал, его заревьювили закоммитили -- не работает, а кто виноват, понятно, не тот кто ценные советы раздавал. Опять же ввиду отсутствия ответственности, ревьювящие занимались просто другой частью проекта.

Вообще суть code review состоит в том, чтобы:

* обнаружить потенциальные ошибки и другие проблемные ситуации в коде;
* оценить хоть как-то архитектурную правильность решения (если, конечно, это видно из кода, часто нет);
* проверить наличие шапок с копирайтами, следование кодстайлу и т.п.

По-моему мнению в нормальной организации к ревью должны привлекаться только люди кровно заинтересованные в продвижении именно этой части проекта в нужную сторону, у ревью должны быть чёткие сроки, например, у каждого должна быть _обязанность_ ежедневно смотреть ревью. Потом чтоб исключить закручивание ревью в 20 итераций должно быть принято правило, что код просматривается один раз и выписываются все замечания. Замечания исправляются или нет, но на очередной итерации в ранее просмотренном коде не должно обнаруживаться что-то новое. Если есть какие-то вопросы, то не нужно устраивать переписку в ревью, а решить их лично, через телефон и т.п., потому, что переписка в ревью опять же вызывает новую итерацию, на которую могут уйти следующие сутки.

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

Зачастую, особенно когда уже есть целая цепочка ревью или отдельная ветка следовало бы как-то документировать работу и я бы советовал писать подробное описание в мерж-коммите (что сделано в целом, в этой ветке, не в деталях, а обощенно, чтоб за деревьями можно было увидеть лес: иначе часто код понятен, а зачем такая масса изменений -- нет). Это имеет отношение к пониманию архитектуры, само архитектурное решение возможно стоит где-то в комментария может, описать на человеческом языке.
Re[6]: Code review (просмотр кода)
От: fk0 Россия https://fk0.name
Дата: 26.04.19 10:58
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Как тогда учить студентов хорошему стилю

RF>>У каждого программиста--свой стиль. Главное, чтобы код был читаемый.
LVV>Нет. Есть общие признаки хорошего стиля.
LVV>Читайте классиков: МакКоннелл, Саттер+Александреску.

С этим трудно поспорить, безусловно общие признаки хорошего стиля есть. Вопрос в их трактовке. И вопрос вообще не технический, не про C++.

Проблема в отсутствии формальных и чётких критериев, что такое хорошо, и что такое плохо. Они субъективны. Вот если бы законы так принимались, это бы работало? Я думаю очевидно, что нет.

И, допустим, рассмотрим работу типичной софтовой фирмы. Где нанято сколько-то программистов и раз в полгода-год действует система награждения хороших и выгоняния плохих (смысл, конечно, не в выгонянии "плохих", реально плохих мало, а в ротации кадров через найм новых более дешёвых сотрудников и в удерживании действительно хороших сотрудников через премирование, например). Это делается так или иначе через KPI реализованный в том или ином виде. Называться оно может какими угодно словами, но в конечном счёте в зачёт пойдут оценки руководителей и/или менеджеров проектов по результатам сделанной работы с их, менеджерской, точки зрения. А с менеджерской точки зрения важны решённые баги, сделанные релизы, достижение поставленных целей. Красивость и качество кода принципиального значения не имеет до тех пор, пока качество кода удовлетворяет с менеджерской точки зрения (проект сделан, багов нет, сроки не затянуты, претензий от заказчика нет).

И вот теперь теперь нехитрая задачка, как оказаться на вершине пирамиды KPI? Для этого совершенно не обязательно выдавать фантастические результаты, более того -- вредно. Проект кончится, что дальше неизвестно. Ну какой автомеханик сделает так, чтоб вы к нему не вернулись ещё раз? Так же и здесь. Но ведь тебя будут сравнивать с другими, выпишут в список, отсортируют по какому-то критерию, голову списка наградят, хвост отрежут. Как оказаться наверху пирамицды, а не в нижнем слое? Кроме очевидной стратегии продираться наверх из последних сил есть более простая: пинками сгонять остальных вниз. Более того, если ты находишься уже близко к вершине или на вершине пирамиды, то выше головы уже не прыгнуть и эта стратегия, сталкивать остальных вниз, остаётся _единственной_. Вроде бы вещь очевидная для тех кто должен уметь управлять людьми.

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

Вот и вся суть грамотного code review. И она ПЕРВИЧНА. Да кого интересует мифическое качество кода? Нормальных людей интересуют регулярные поступления денежных средств в карман. А там -- пирамида описанная выше. То, что в подчинённые нужно вытягивать полных дураков я вообще не от программистов услышал, примерно в таком же ключе рассуждений. Не надо думать, что у программистов будет по-другому.

Конечно, если пирамиду сделать безразмерной, бесконечно высокой, то проблема уходит тоже куда-то в бесконечность. Но как правило пирамидка маленькая и над ней стеклянный потолок. А за ним менеджеры и директора.
Re[2]: Code review (просмотр кода)
От: igor-booch Россия  
Дата: 26.04.19 11:20
Оценка:
Все ли участники команды согласны с тем, что code review приносит выгоду?

Оправдываются трудозатраты на проведение CR и на исправления по результатам CR? Не бывает ли так, что ради соблюдения, какого-либо принципа проектирования, на котором кто-нибудь настаивает, код в итоге значительно усложняется, срываются сроки, падает производительность, мотивация, настроение? На мой взгляд, зрелость разработчика заключает не в знании и фанатичном соблюдении всех принципов проектирования, а знании где и когда эти принципы нужно соблюсти любой ценой, а где можно|лучше не соблюдать.

Не сопровождается ли CR взаимные уступками (я лояльно отношусь к твоему коды, а ты к моему) или, наоборот, местью (ты ко мне придерешься, я к тебе буду придраться).

Есть ли член команды с правом решающего голоса?

Кто обладает правом "вето"?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Отредактировано 26.04.2019 11:46 igor-booch . Предыдущая версия . Еще …
Отредактировано 26.04.2019 11:44 igor-booch . Предыдущая версия .
Отредактировано 26.04.2019 11:22 igor-booch . Предыдущая версия .
Отредактировано 26.04.2019 11:21 igor-booch . Предыдущая версия .
Отредактировано 26.04.2019 11:21 igor-booch . Предыдущая версия .
Re[3]: Code review (просмотр кода)
От: okman Беларусь https://searchinform.ru/
Дата: 26.04.19 13:43
Оценка: 8 (2)
Здравствуйте, igor-booch, Вы писали:

IB>Все ли участники команды согласны с тем, что code review приносит выгоду?


Не могу сказать за всех, но вроде бы у нас внедрению CR никто особо не сопротивлялся.

IB>Оправдываются трудозатраты на проведение CR и на исправления по результатам CR?


Субъективно:
У нас ревью занимает обычно от получаса до нескольких часов. Иногда вылавливаются довольно тонкие дефекты. Если бы такие
дефекты уходили вместе с версией на тест, их бы обнаруживали в лучшем случае через несколько дней, а то и позже,
когда версия уйдет в релиз. Это не допустимо. Потратить час-два несколько раз в месяц — это достаточно небольшая
плата за CR, я считаю. К тому же есть стажеры и вообще люди, которые в проекте недавно, за ними нужен усиленный
контроль, без CR здесь никуда.

IB>Не бывает ли так, что ради соблюдения, какого-либо принципа проектирования, на котором кто-нибудь настаивает,

IB>код в итоге значительно усложняется, срываются сроки, падает производительность, мотивация, настроение?

Не припомню такого. Мы относимся к CR без фанатизма, должен где-то быть баланс между качеством кода (которое можно улучшать до
бесконечности, но в какие сроки и какой ценой?) и поставкой запланированных фич клиентам. Для бизнеса важнее второе, это все понимают.

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


У нас CR — это не стремление любой ценой привести код к 100% идеалу, выбросив без сожаления все, что не
попадает под это определение, а просто некий процесс коллективной оценки кода с целью недопущения явных дефектов и
откровенно плохих практик.

IB>Не сопровождается ли CR взаимные уступками (я лояльно отношусь к твоему коды, а ты к моему) или, наоборот, местью (ты ко мне придерешься, я к тебе буду придраться).


Местью — точно нет
По поводу уступок... Есть старые кодовые базы, которые "просто работают". Код там, мягко говоря, не очень.
И они тоже принимаются. Главное, чтобы новый код не содержал откровенных дефектов.

IB>Есть ли член команды с правом решающего голоса?

IB>Кто обладает правом "вето"?

В общем случае, замечания участников равноценны. Если возникают споры — вмешиваются начальники отделов и тогда
решаем: "вливать", "не вливать" или "влить, но позже исправить".
Re[6]: Code review (просмотр кода)
От: Lexey Россия  
Дата: 26.04.19 14:35
Оценка: +3 :)
Здравствуйте, so5team, Вы писали:

RF>>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.


S>Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно, без выходных и проходных. Начиная с азов: с правил именования сущностей, с декомпозиции данных, с декомпозиции функций и т.д.


Скорее, такой код никогда не попал бы в репозиторий, так что до рефакторинга просто не дошло бы.

S>А у совсем невменяемых, таких как я, вы бы и до испытательного срока не дошли.


У вполне вменяемых тоже не дошел бы, скорее всего.

P.S. А ТС случаем не жирный тролль? Что-то не верится с существование программиста с таким незамутненным сознанием.
"Будь достоин победы" (c) 8th Wizard's rule.
Re[2]: Code review (просмотр кода)
От: Submitter  
Дата: 26.04.19 14:47
Оценка:
Здравствуйте, CreatorCray, Вы писали:

RF>>Уважаемые коллеги, предлагаю вам обсудить $SUBJECT_NAME

RF>>В чём заключается $SUBJECT_NAME? Есть ли у вас на работе $SUBJECT_NAME и $MORE_QUESTIONS?

На PHP пишешь?

CC>Ну как бы только совсем с тобой не знакомые на такое должны клевать.


+1
Re[7]: Code review (просмотр кода)
От: so5team https://stiffstream.com
Дата: 26.04.19 15:05
Оценка: +1
Здравствуйте, Lexey, Вы писали:

L>P.S. А ТС случаем не жирный тролль?


Были такие подозрения пока на какие-то его вопросы в профильных форумах по C++ не наткнулся.

L>Что-то не верится с существование программиста с таким незамутненным сознанием.


Доводилось видеть отдельных похожих "специалистов". Но в бюджетных или околобюджетных НИИ. Возможно, в каких-то заштатных ВУЗах таких же можно отыскать в штучных экземплярах.
Re[7]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 26.04.19 15:08
Оценка:
fk0> Вот и вся суть грамотного code review. И она ПЕРВИЧНА. Да кого интересует мифическое качество кода? Нормальных людей интересуют регулярные поступления денежных средств в карман. А там -- пирамида описанная выше. То, что в подчинённые нужно вытягивать полных дураков я вообще не от программистов услышал, примерно в таком же ключе рассуждений. Не надо думать, что у программистов будет по-другому.
У нас денежный стимул отсутствует.
Поэтому впереди — то самое мифическое качество кода.
И напомню, что есть книжка от Микрософт "Инфраструктура программных проектов".
Тоже неплохие рекомендации прописаны.
А также есть книжка Джуста Виссера "Разработка обслуживаемых программ на языке С#".
И такая же от него по Java.
Там вполне конкретные рекомендации.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: Code review (просмотр кода)
От: mgu  
Дата: 26.04.19 21:51
Оценка: :)
Здравствуйте, Bj777x, Вы писали:


S>>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно, без


B>Етить колотить, там только goto не хватает доя полного комплекта


А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить.
Re[6]: Code review (просмотр кода)
От: mgu  
Дата: 26.04.19 21:53
Оценка: :)))
Здравствуйте, so5team, Вы писали:

S>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно,


        AfxMessageBox(L"Расчёт параметров схода КО с орбиты\nи времени его баллистического существования завершён");


Так это же rocket science!
Re[6]: Code review (просмотр кода)
От: Эйнсток Файр Мухосранск Странный реагент
Дата: 26.04.19 23:58
Оценка: :)))
LVV>Я один могу преподавать всю программерскую и математическую часть учебного плана.

А процессор голыми руками в чистом поле из песка изготовить сможете, или нехватает практических навыков?
Отредактировано 27.04.2019 1:39 Эйнсток Файр . Предыдущая версия .
Re[8]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 27.04.19 03:59
Оценка:
mgu>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить.
Опять же — читайте классиков!
Писал Дейкстра, писал Кнут.
Но статьи старые, в русском инете не найти. Может быть, есть в английском.
Основная мысль состоит в том, что такой код (напичканный goto)
а) трудно читать
б) трудно модифицировать.
Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход.
Это значительно упрощает как чтение, так и модификацию.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Отредактировано 27.04.2019 4:06 LaptevVV . Предыдущая версия .
Re[9]: Code review (просмотр кода)
От: fk0 Россия https://fk0.name
Дата: 27.04.19 07:40
Оценка: +1
Здравствуйте, 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" сколько выходов? Если ветви по которым может пойти вычисление две.
Re[10]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 27.04.19 10:26
Оценка:
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.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[10]: Code review (просмотр кода)
От: Sheridan Россия  
Дата: 27.04.19 11:53
Оценка: :))
Здравствуйте, Pzz, Вы писали:

Pzz>Компилятор и не следит, следит отдельная утилита. Компилятору, по большому счету, все равно, а вот любой IDE навязывает стиль, причем один и тот же. Это раздражает первые два дня, а потом понимаешь, что это правильно.

Да? Ну попробуй в другом редакторе написать и скомпилировать потом.

Pzz>Что до школоты, это вряд ли. Ключевые люди там, в основном, все взрослые и уже отметившиеся в более других общеизвестных проектах (некоторые из этих проектов, впрочем, нонешняя школота может и не упомнить).

Тем не менее это сраные уроды.
Matrix has you...
Re[11]: Code review (просмотр кода)
От: fk0 Россия https://fk0.name
Дата: 27.04.19 19:34
Оценка: +2
Здравствуйте, 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 -- костыль, причём плохой.
Re[9]: Code review (просмотр кода)
От: mgu  
Дата: 27.04.19 22:36
Оценка:
Здравствуйте, LaptevVV, Вы писали:

mgu>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить.

LVV>Опять же — читайте классиков!
LVV>Писал Дейкстра, писал Кнут.
LVV>Но статьи старые, в русском инете не найти. Может быть, есть в английском.

Ну, классики много чего говорили. И про богоугодность каскадной разработки, и про 640 килобайт памяти, и про важность гномиков на интервью.

LVV>Основная мысль состоит в том, что такой код (напичканный goto)

LVV>а) трудно читать
LVV>б) трудно модифицировать.
LVV>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход.

Меня терзают смутные сомнения, что return -- это замаскированный goto.

LVV>Это значительно упрощает как чтение, так и модификацию.


С таким подходом бывает, что код заносит вправо за область видимости монитора.

Кстати, "ОДИН выход" уже несколько лет как подвергли анафеме. Ещё недавно в обязательный номер цирковой программы на интервью входило прочитать "catch наш" в правильном порядке. А нынче во все стороны кидаются исключениями, событиями и задержками.

А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься.
А ещё есть yield -- это вообще проходной двор.
Отредактировано 27.04.2019 23:10 mgu . Предыдущая версия .
Re[3]: Code review (просмотр кода)
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.04.19 02:14
Оценка:
Здравствуйте, RussianFellow, Вы писали:

RF>Когда я учился в институте, у нас не было никакого code review. И на нынешней и на всех предыдущих работах у меня не было никакого code review.

RF>Главное--чтобы код работал и работал правильно.

Судя по всему, что ты тут пишешь — у вас за ревью прораб отвечает, он же сапогами и пинает непрошедших его прораб-ревью
Маньяк Робокряк колесит по городу
Re[6]: Code review (просмотр кода)
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.04.19 02:16
Оценка:
Здравствуйте, kaa.python, Вы писали:

V_S>>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?


KP>Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?


Может тем, что он сам никогда не проходил никаких код-ревью?
Маньяк Робокряк колесит по городу
Re[7]: Code review (просмотр кода)
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.04.19 02:18
Оценка: :))
Здравствуйте, Vlad_SP, Вы писали:

KP>>Какой-то стиль всяко нужно взять за образец и считать именно его правильным. Чем стиль профессора плохой образец для студентов?


V_S>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.


За оформление кода в стиле KnR пожизненный эцих с гвоздями
Маньяк Робокряк колесит по городу
Re[8]: Code review (просмотр кода)
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.04.19 02:20
Оценка:
Здравствуйте, Pzz, Вы писали:

V_S>>Стиль профессора может быть и не плохой образец для студентов. Однако если цель кодревью — только "исправление стиля", типа исправления расстановки скобочек (Kernighan vs Allman etc.), то это пустая трата времени.


Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.



Это что, в Го как Пайтоне? Или это просто какой-то "правильный" редактор следит, но в общем случае пох?
Маньяк Робокряк колесит по городу
Re[6]: Code review (просмотр кода)
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.04.19 02:23
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Как тогда учить студентов хорошему стилю и рефакторингу?

V_S>>Валерий Викторыч, это отнюдь не кодревью и не "хороший стиль", а — "стиль, который нравится профессору". Ваш-то код кто-нибудь ревьюит?
LVV>"Мастерство не пропьешь"(с)...
LVV>Около 50 лет опыта, прочитано литературы едва ли не больше всех в России.

Это серьёзная заявка
Маньяк Робокряк колесит по городу
Re[6]: Code review (просмотр кода)
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.04.19 02:24
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Как тогда учить студентов хорошему стилю

RF>>У каждого программиста--свой стиль. Главное, чтобы код был читаемый.
LVV>Нет. Есть общие признаки хорошего стиля.
LVV>Читайте классиков: МакКоннелл, Саттер+Александреску.

Вот Александреску как пример для подражания так себе
Маньяк Робокряк колесит по городу
Re[9]: Code review (просмотр кода)
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.04.19 02:27
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

mgu>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить.

LVV>Опять же — читайте классиков!

Для плюсов готу ломает автоматику управления локальными объектами, не?
Маньяк Робокряк колесит по городу
Re[7]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 28.04.19 04:14
Оценка:
LVV>>Нет. Есть общие признаки хорошего стиля.
LVV>>Читайте классиков: МакКоннелл, Саттер+Александреску.
M>Вот Александреску как пример для подражания так себе
Я — про общую их книжку по стилю программирования на С++.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 28.04.19 04:18
Оценка:
LVV>>"Мастерство не пропьешь"(с)...
LVV>>Около 50 лет опыта, прочитано литературы едва ли не больше всех в России.
M>Это серьёзная заявка
А то...
Но, конечно, чтобы читать какой-то курс — надо к нему готовиться полгода.
В свое время, лет 20 назад, наш тогдашний завкаф сказала: Лаптева клонировать надо.
Что ни спросишь — он знает, в каких книжках и что прочитать...
А вообще-то после разработки и написания бортовой оси — что может быть непонятного в программировании?
Вопрос только во времени — готовиться надо.
Самое сложное — лабы продумать и написать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[10]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 28.04.19 04:32
Оценка:
mgu>>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить.
LVV>>Опять же — читайте классиков!
LVV>>Писал Дейкстра, писал Кнут.
LVV>>Но статьи старые, в русском инете не найти. Может быть, есть в английском.
mgu>Ну, классики много чего говорили. И про богоугодность каскадной разработки, и про 640 килобайт памяти, и про важность гномиков на интервью.
Ну, это не классики...
...
mgu>Кстати, "ОДИН выход" уже несколько лет как подвергли анафеме. Ещё недавно в обязательный номер цирковой программы на интервью входило прочитать "catch наш" в правильном порядке. А нынче во все стороны кидаются исключениями, событиями и задержками.
Ну, пишите, как хотите. Структурное программирование — это только рекомендации...
mgu>А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься.
А это вообще не язык программирования
mgu>А ещё есть yield -- это вообще проходной двор.
Это в питоне, что ли?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[8]: Code review (просмотр кода)
От: AlexGin Беларусь  
Дата: 28.04.19 05:06
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Нет. Есть общие признаки хорошего стиля.

LVV>>>Читайте классиков: МакКоннелл, Саттер+Александреску.
M>>Вот Александреску как пример для подражания так себе
LVV>Я — про общую их книжку по стилю программирования на С++.

Это про "Стандарты прогрпммарования на C++" Герб Саттер, Андрей Александреску?
Если так, то это великолепная книга. Авторы всё очень толково изложили.
Re[10]: Code review (просмотр кода)
От: AlexGin Беларусь  
Дата: 28.04.19 06:15
Оценка: +1
Здравствуйте, mgu, Вы писали:

mgu>Меня терзают смутные сомнения, что return -- это замаскированный goto.


Нет, это НЕ замаскированный goto!

Ключевое отличие return — переход НЕ ПО МЕТКЕ, а по сохраненному в стеке адресу возврата.
Это позволяет передавать управление не на фиксированную точку, а именно туда, откуда был вызов.
Отредактировано 28.04.2019 6:22 AlexGin . Предыдущая версия .
Re: Статья от Яндекса по code review
От: LaptevVV Россия  
Дата: 28.04.19 06:36
Оценка:
https://habr.com/ru/company/yamoney/blog/446654/
Конкретный опыт по улучшению этого процесса.

Правильное код-ревью — это как?

Мы выделили четыре пункта, которые должны быть в обновленном код-ревью:

1. Проверка архитектуры решения. Довольно очевидная вещь. Ожидаем это от старших разработчиков с экспертизой в данном компоненте.
2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте.
3. Передача знаний, которая заключается в изучении бизнес-логики и кодовой базы новичками и джунами посредством код-ревью.
4. Возможность оценки hard skills разработчиков. Хочется, чтобы за каждым разработчиком был закреплен наставник, который оценивает рост, определяет вектор развития, подмечает какие-то недостатки, делает замечания и так далее. Поэтому наставник также должен видеть код своих подопечных.

Возможно, кто-то видит другие цели или не согласен с нашими — делитесь в комментариях. А я пока перейду от формулирования целей к поиску средств их достижения – мы решили, что хотим достичь их все и (почти) сразу.

Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: Code review (просмотр кода)
От: AlexGin Беларусь  
Дата: 28.04.19 06:47
Оценка: +1
Здравствуйте, anton_t, Вы писали:

_>Здравствуйте, so5team, Вы писали:


S>> подобных творений
Автор: RussianFellow
Дата: 11.04.19


_>Душераздирающее зрелище

+100500
Из серии "антипаттерн" или: как нельзя писать на C++
Re[10]: Code review (просмотр кода)
От: Stanislav V. Zudin Россия  
Дата: 28.04.19 07:33
Оценка:
Здравствуйте, Marty, Вы писали:

mgu>>>А что плохого в goto? Когда-то написали в газете "Правда", что это плохо, и все повторяют, но никто не может объяснить.

LVV>>Опять же — читайте классиков!

M>Для плюсов готу ломает автоматику управления локальными объектами, не?


Компиляторы сейчас за этим следят, но для POD типов можно такого наколбасить...
_____________________
С уважением,
Stanislav V. Zudin
Re[8]: Code review (просмотр кода)
От: LuciferNovoros Россия  
Дата: 28.04.19 16:42
Оценка: +3
Здравствуйте, AlexGin, Вы писали:

AG>Из серии "антипаттерн" или: как нельзя писать на C++


И не только. Так нельзя писать ни на одном ЯП.
Re[2]: Статья от Яндекса по code review
От: Lazy Bear Канада  
Дата: 28.04.19 17:28
Оценка: +1 -1
Здравствуйте, LaptevVV, Вы писали:

LVV>2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте.


Экспертиза бывает судебно-медицинская, например. А здесь должно быть написано "являющихся экспертами" или "имеющих опыт работы". Двоечники, блин! Мидлы!
Re[7]: это же rocket science!
От: Lazy Bear Канада  
Дата: 28.04.19 17:37
Оценка: :))) :))) :)
Здравствуйте, mgu, Вы писали:

S>>Возможно, это потому, что ваши руководители оказывались еще менее компетентными программистами, чем вы. Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно,


AfxMessageBox(L"Расчёт параметров схода КО с орбиты\nи времени его баллистического существования завершён");

mgu>Так это же rocket science!

Вот мы и нашли виновника проблем в космической отрасли
Отредактировано 28.04.2019 17:38 Lazy Bear . Предыдущая версия .
Re[8]: это же rocket science!
От: Эйнсток Файр Мухосранск Странный реагент
Дата: 28.04.19 18:09
Оценка:
LB> Вот мы и нашли виновника проблем в космической отрасли

Но ты сделал для российской космической области меньше, чем он,
поэтому ты больше виновник. Предлагаю тебя расстрелять забанить.
Отредактировано 28.04.2019 18:10 Эйнсток Файр . Предыдущая версия .
Re[9]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.04.19 18:58
Оценка:
Здравствуйте, Marty, Вы писали:

M>Это что, в Го как Пайтоне? Или это просто какой-то "правильный" редактор следит, но в общем случае пох?


Нет, не как в питоне. Но есть стандартный форматер, и все IDE его используют. Но можно без IDE, никто не заставляет.
Re[9]: это же rocket science!
От: Lazy Bear Канада  
Дата: 28.04.19 19:37
Оценка:
Здравствуйте, Эйнсток Файр, Вы писали:

LB>> Вот мы и нашли виновника проблем в космической отрасли


ЭФ>Но ты сделал для российской космической области меньше, чем он,

ЭФ>поэтому ты больше виновник. Предлагаю тебя расстрелять забанить.

Я сделал больше, ведь я нашел виновника. Меня надо поощрить. А тебя предлагаю на всякий случай расстрелять забанить.
Re[10]: это же rocket science!
От: LuciferNovoros Россия  
Дата: 29.04.19 05:47
Оценка: +1 :)
Здравствуйте, Lazy Bear, Вы писали:

LB>Я сделал больше, ведь я нашел виновника. Меня надо поощрить. А тебя предлагаю на всякий случай расстрелять забанить.


Зачем сразу банить? Можно на ревью кода от Русского Парня посадить. Пожизненно.
Re[4]: Code review (просмотр кода)
От: Privalov  
Дата: 29.04.19 06:57
Оценка:
Здравствуйте, okman, Вы писали:

IB>>Все ли участники команды согласны с тем, что code review приносит выгоду?


<Offtopic>
Блин, не сразу понял, что такое CR. У нас CR — это Change Request.
</Offtopic>
Re[6]: Code review (просмотр кода)
От: Privalov  
Дата: 29.04.19 07:06
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>"Мастерство не пропьешь"(с)...


Оно, конечно, так. Но иногда некоторые коллеги присылают мне жалобы: такой-то участок кода не работает. Я открываю. Первая реакция: какой идиот это написал? Чуть позже с глаз спадает пелена, и я вижу: код — мой. Сделан так, что строка, добавленная коллегой, его сломала. Видимо, писался в спешке. А может, сейчас требования изменились. Деталей не помню, код написан несколько лет назад. И приходится мне правки в него вносить самому.
Конечно, это не типичный случай. Но всякой бываеь.
Re[11]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 29.04.19 07:11
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Писал Дейкстра, писал Кнут.

fk0>> Что бы они ни писали, не нужно их считать безусловными авторитетами претендующими на абсолютное знание.
LVV>В данном случае конкретно статья Кнута была не мнением, а исследованием.
Нет таких исследований.

LVV>Вывод Кнута (на основании исследований кода программ на фортране) однозначен: использование goto без должной дисциплины приводит к большему количеству ошибок.

Нет.

Использование goto для прыжков назад приводит к увеличению ошибок. Использование goto для прыжков вперёд количество ошибок уменьшает. Это было проверено уже много раз в проектах, которые пишутся на С.

Но по какой-то идиотской причине до университетов это до сих пор не дошло. Видимо, из-за того, что преподаватели практическим программированием занимаются мало.
Sapienti sat!
Re[11]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 29.04.19 07:18
Оценка: :))
Здравствуйте, LaptevVV, Вы писали:

fk0>> Но for, while -- тоже замаскированные goto. А switch-case в C/C++ вообще страшная вещь в контексте того, что case можно вставлять в середину какого-либо другого цикла или даже ветви if'а. Если развивать мысль в этом направлении дальше, то циклы стоит запретить и всё делать через рекурсию. Разговоры вокруг и около goto сводятся к поговорке "заставь дурака богу молиться..."

LVV>Ни for, ни while не являются замаскированными goto.
Да ну? А если дизассемблером посмотреть?
Sapienti sat!
Re[7]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 29.04.19 07:38
Оценка: 6 (1)
LVV>>"Мастерство не пропьешь"(с)...
P>Оно, конечно, так. Но иногда некоторые коллеги присылают мне жалобы: такой-то участок кода не работает. Я открываю. Первая реакция: какой идиот это написал? Чуть позже с глаз спадает пелена, и я вижу: код — мой. Сделан так, что строка, добавленная коллегой, его сломала. Видимо, писался в спешке. А может, сейчас требования изменились. Деталей не помню, код написан несколько лет назад. И приходится мне правки в него вносить самому.
P>Конечно, это не типичный случай. Но всякой бываеь.
Бывает. Я для этого применяю ТОТАЛЬНЫЙ коммент.
Студенты не верят, что я могу открыть прогу 7-летней давности и все по ней рассказать.
Когда видят комменты — глаза на лоб лезут: комментов больше кода...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[12]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 29.04.19 07:40
Оценка:
LVV>>В данном случае конкретно статья Кнута была не мнением, а исследованием.
C>Нет таких исследований.
Найду ссыль — пришлю.
LVV>>Вывод Кнута (на основании исследований кода программ на фортране) однозначен: использование goto без должной дисциплины приводит к большему количеству ошибок.
C>Нет.
C>Использование goto для прыжков назад приводит к увеличению ошибок. Использование goto для прыжков вперёд количество ошибок уменьшает. Это было проверено уже много раз в проектах, которые пишутся на С.
Это было задолго до С — еще для фортрана. И как раз Кнутом.
C>Но по какой-то идиотской причине до университетов это до сих пор не дошло. Видимо, из-за того, что преподаватели практическим программированием занимаются мало.
Если до американских не дошло, то это ИХ проблемы...
У нас — все дошло.
Пишем вообще без goto...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[11]: Code review (просмотр кода)
От: Privalov  
Дата: 29.04.19 07:55
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Вывод Кнута (на основании исследований кода программ на фортране) однозначен: использование goto без должной дисциплины приводит к большему количеству ошибок.

LVV>Это — НАУЧНЫЙ результат.
LVV>>>Основная мысль состоит в том, что такой код (напичканный goto)
LVV>>>а) трудно читать
LVV>>>б) трудно модифицировать.


А как ты в Фотране 4 сделаешь цикл типа while без goto вверх?
Можно использовать обычный цикл do, но там нужно переменную цикла модифицировать где-то по ходу действия. Такой код гораздо менее понятен, чем просто goto вверх.
Ну, еще можно использовать арифметический if. В нем слова goto нет, не так раздражает. Я постоянно так делал.

Да, я знаю, что Фортран 4 для новых проектов не используется. Но за десятиления на нем накопилась масса работающего кода. Его используют.

А goto вниз — это вполне нормально. В Java break не метку не просто так придумали. Выход из кучи вложенных циклов, освобождение ресурсов в C, да мало ли.
Re[11]: Code review (просмотр кода)
От: Privalov  
Дата: 29.04.19 08:05
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Ну, пишите, как хотите. Структурное программирование — это только рекомендации...


Увидел словосочетание "структурное программирование" и вспомнил случай из прошлого. Я о нем уже как-то рассказывал, ЕМНИП.
Зашел я как-то в одну контору к приятелям по какому-то поводу. А у нах какая-то ерунда с компом приключилась. Деталей не помню. Только предложил я им попробовать натравить на эту ерунду утилитку, которую я сделал несколькими днями раньше. Делов на несколько сотен строк.
Запустили ее. Вижу, работает.
И увидел я там одного препода не то информатики, не то программирования. Адепт структурного программирования. Я шапочно был с ним знаком. И что-то он кому-то задвигал о вреде goto. И рассказывал азбучные истины структурного программирования. А я возьми и покази ему на комп, где моё творение работало. Вот в той программе, говорю, есть один goto, который экономит строки кода и облегчает отладку. Препода бомбануло, "я бы тебе зачет не поставил", все дела. Но коллеги пиво поставили мне за вовремя принесенную программу, а не ему за отстаивание принципов структурного программирования.
Позже выяснилось: этот препод не знал, что номера строк в Васике давно отменили. Но это уже другая история.
Re[8]: Code review (просмотр кода)
От: Privalov  
Дата: 29.04.19 08:20
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Бывает. Я для этого применяю ТОТАЛЬНЫЙ коммент.

LVV>Студенты не верят, что я могу открыть прогу 7-летней давности и все по ней рассказать.
LVV>Когда видят комменты — глаза на лоб лезут: комментов больше кода...

Я сейчас редко оставляю в коде комментарии. Обычно они нужны, когда требуется не забыть что-нибудь допилить. После допиливания комментарии убираются. Время 2-х и 6-символьных идентификаторов прошло.
Иногда комментировал чужой код, написанный в стиле Фортрана 4. Но это для себя, когда копать приходилось. Некоторые умудрялись писать такой код даже на FoxPro, в котором goto по записям, а не по коду, бегает.
Re[8]: Code review (просмотр кода)
От: Privalov  
Дата: 29.04.19 08:24
Оценка: +1
Здравствуйте, AlexGin, Вы писали:

_>>Душераздирающее зрелище

AG>+100500
AG>Из серии "антипаттерн" или: как нельзя писать на C++

Да уж.
Старшие товарищи на Фортране 4 лучше писали.
Re[8]: Code review (просмотр кода)
От: Skorodum Россия  
Дата: 29.04.19 09:06
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.

В С++ IDE уже умеют форматировать код по мере набора с помощью clang-format (не только отступы, а именно продвинутое форматирование: скобочки, пробелы, перенос строк и т.п.). Стиль какой хочешь можно определить.
Re[9]: Code review (просмотр кода)
От: Skorodum Россия  
Дата: 29.04.19 09:07
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle.

Нормальные утилиты на компиляторе и основаны: clang-format. Просто по ключевым словам С++ полноценно не отформатируешь.
Re[9]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 29.04.19 10:47
Оценка:
P>Я сейчас редко оставляю в коде комментарии. Обычно они нужны, когда требуется не забыть что-нибудь допилить. После допиливания комментарии убираются. Время 2-х и 6-символьных идентификаторов прошло.
У меня была другая картина.
Научник использовал научные обозначения величин, принятые во всем мире и прописанные во всех статьях...
И настоятельно мне рекомендовал использовать эти имена для соответствующих переменных.
Ибо я когда-нить перестану у него работать, а ему потом разбираться...
Вот и приходилось однобуквенные имена комментариями обкладывать.
P>Иногда комментировал чужой код, написанный в стиле Фортрана 4. Но это для себя, когда копать приходилось. Некоторые умудрялись писать такой код даже на FoxPro, в котором goto по записям, а не по коду, бегает.
Я вот прямо сейчас код курсовой одного студня правлю.
Сижу, комменты добавляю — чтобы понятней ему тоже было...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[12]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 29.04.19 11:01
Оценка:
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
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Отредактировано 29.04.2019 11:02 LaptevVV . Предыдущая версия .
Re[10]: Code review (просмотр кода)
От: Privalov  
Дата: 29.04.19 11:28
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>И настоятельно мне рекомендовал использовать эти имена для соответствующих переменных.

LVV>Ибо я когда-нить перестану у него работать, а ему потом разбираться...
LVV>Вот и приходилось однобуквенные имена комментариями обкладывать.

Это был суровый матан?
У математиков давно принята система именования идентификаторов. Наверное, она в каждом коллективе своя. Но имена типа FP12K2 никого не смущали. В 6 символов математики умудрялись заложить глубокий смысл. Они и сейчас так пишут.
А почему односимвольные имена? Даже в "Искре-226" допускались двухсимвольные. Второй символ обязательно цифра. Вот это был клинический случай. Приходилось специальный документ, описывающий идентификаторы, составлять. Потому что программа с комментариями могла в память не уместиться.

LVV>Я вот прямо сейчас код курсовой одного студня правлю.

LVV>Сижу, комменты добавляю — чтобы понятней ему тоже было...

Так вставь ему пистон на ближайшей проработке. Ведь скажет же потом: это не я, это препод мне посоветовал так писать.
Re[3]: Статья от Яндекса по code review
От: std.denis Россия  
Дата: 29.04.19 11:36
Оценка:
LVV>>2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте.
LB>Экспертиза бывает судебно-медицинская, например. А здесь должно быть написано "являющихся экспертами" или "имеющих опыт работы". Двоечники, блин! Мидлы!

Да пора привыкнуть к этому карго-культу, уже везде эту прямую кальку используют любители показаться важными и идущими в ногу с.
Re[8]: Code review (просмотр кода)
От: Anonymous123 Чехия  
Дата: 29.04.19 12:10
Оценка:
Здравствуйте, 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."
Re[10]: Code review (просмотр кода)
От: Sheridan Россия  
Дата: 29.04.19 13:15
Оценка: +2
Здравствуйте, Skorodum, Вы писали:

S>>Уроды это придумали. Недоучившаяся школота, не знающая инструментария. Не должен компилятор следить за стилем, для этого отдельные утилиты есть, тот же astyle.

S>Нормальные утилиты на компиляторе и основаны: clang-format. Просто по ключевым словам С++ полноценно не отформатируешь.

Ключевое: "на основе". Не часть компилятора, а отдельная утилита. На секундочку, настраиваемая.
А не так как у goвноавторов — стиль прибит гвоздями к компилятору.
Matrix has you...
Re[9]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 29.04.19 14:01
Оценка:
Здравствуйте, Skorodum, Вы писали:

Pzz>>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.

S>В С++ IDE уже умеют форматировать код по мере набора с помощью clang-format (не только отступы, а именно продвинутое форматирование: скобочки, пробелы, перенос строк и т.п.). Стиль какой хочешь можно определить.

Ну я в Go стиль один на всех.
Re[13]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 29.04.19 16:36
Оценка:
Здравствуйте, 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 вперёд. Они фундаментально отличаются.
Sapienti sat!
Re: Code review (просмотр кода)
От: B0FEE664  
Дата: 29.04.19 16:38
Оценка:
Здравствуйте, RussianFellow, Вы писали:

RF>Уважаемые коллеги, предлагаю вам обсудить такую тему, как code review (просмотр кода).


Так как я пишу без ошибок, то делать Code review моего кода всем быстро надоедает. Последний code review свёлся к переписываю кода из стиля
Круговая оборона к стилю Контрактное программирование. Это произошло из-за того, что меня заранее не предупредили в каком стиле писать код.

Когда же я делаю code review, то обычно ищу (и нахожу) фактические ошибки, не выловленные при тестировании, к полному неудовольствию начальника проекта. Так как я работаю иностранным консультантом, то приходится проявляеть дипломатические способности и толерантно относиться ко многим нарушениям наилучших практик программирования. Например, если в спецификациях записано, что код должен соответсвововать MISRA C++, то найти список несоответствий довольно просто, однако практика показывает, что далеко не всегда после этого код будет исправлен, так как на работоспособность кода это не влияет.
И каждый день — без права на ошибку...
Re[13]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 29.04.19 16:41
Оценка:
Здравствуйте, LaptevVV, Вы писали:

C>>Использование goto для прыжков назад приводит к увеличению ошибок. Использование goto для прыжков вперёд количество ошибок уменьшает. Это было проверено уже много раз в проектах, которые пишутся на С.

LVV>Это было задолго до С — еще для фортрана. И как раз Кнутом.
То что бред сказали ещё до С — меньше бредом не становится.

C>>Но по какой-то идиотской причине до университетов это до сих пор не дошло. Видимо, из-за того, что преподаватели практическим программированием занимаются мало.

LVV>Если до американских не дошло, то это ИХ проблемы...
До американских дошло, что современная практика слегка отличается от 1960-го.

LVV>У нас — все дошло.

Ага, потому спутники и падают. Одна точка выхода из функции полёта — в Тихий океан.

LVV>Пишем вообще без goto...

Ну да, прививаете бредовые привычки с детства.
Sapienti sat!
Re[11]: Code review (просмотр кода)
От: mgu  
Дата: 29.04.19 22:04
Оценка:
Здравствуйте, LaptevVV, Вы писали:

mgu>>А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься.

LVV>А это вообще не язык программирования

Буква L как бы намекает. Просто синтаксис не си-подобный.

mgu>>А ещё есть yield -- это вообще проходной двор.

LVV>Это в питоне, что ли?

И там тоже.
Re[4]: Статья от Яндекса по code review
От: mgu  
Дата: 29.04.19 23:19
Оценка:
Здравствуйте, std.denis, Вы писали:

LVV>>>2. Проверка технической реализации, которую ожидаем также от старших и мидлов с экспертизой в данном компоненте.

LB>>Экспертиза бывает судебно-медицинская, например. А здесь должно быть написано "являющихся экспертами" или "имеющих опыт работы". Двоечники, блин! Мидлы!

SD>Да пора привыкнуть к этому карго-культу, уже везде эту прямую кальку используют любители показаться важными и идущими в ногу с.


Уже?

Но панталоны, фрак, жилет,
Всех этих слов на русском нет;
А вижу я, винюсь пред вами,
Что уж и так мой бедный слог
Пестреть гораздо б меньше мог
Иноплеменными словами,

Re[12]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 30.04.19 03:51
Оценка:
mgu>>>А в старом добром HTML-е один вход, а выхода нет. При этом к структурированности не придерёшься.
LVV>>А это вообще не язык программирования
mgu>Буква L как бы намекает. Просто синтаксис не си-подобный.
Буквы P нет...
mgu>>>А ещё есть yield -- это вообще проходной двор.
LVV>>Это в питоне, что ли?
mgu>И там тоже.
И ЧО?
Структурное программирование касается внутренней организации кода в процедурах и функциях.
В однопроцессорной схеме.
B прекрасно себя показало и показывает.
Несмотря ни на какие yieldы...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[14]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 30.04.19 03:56
Оценка:
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 вперёд. Они фундаментально отличаются.
Твое слово против слова Кнута.
Но у Дональда, по крайней мере, статья есть. А у тебя — нет.
Если есть — давай, почитаю.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[15]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 30.04.19 06:50
Оценка: 7 (2) +1
Здравствуйте, LaptevVV, Вы писали:

LVV>>>https://web.archive.org/web/20130731202547/http:/pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

C>>Это не исследование. Кроме того, там не разделяется goto назад и goto вперёд. Они фундаментально отличаются.
LVV>Твое слово против слова Кнута.
В отличие от Кнута, я занимаюсь реальным промышленным программированием. Он не занимается.

И я не излагаю какое-то особенно странное мнение, goto для обработки ошибок и выхода из глубоких циклов является общепризнанным инструментом в С. Например, вот от Линуса: https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/

Напоминаю, Линус Торвальдс — это человек, который на протяжении 20 лет руководит крупнейшим и самым сложным Open Source проектом на С.

LVV>Но у Дональда, по крайней мере, статья есть. А у тебя — нет.

LVV>Если есть — давай, почитаю.
http://www.se.rit.edu/~mei/publications/pdfs/An-Empirical-Study-of-Goto-in-C-Code-from-GitHub-Repositories.pdf — примерно такого же уровня, что и кнутовское сочинение на тему: "Что я делал этим летом".

Ну и напоследок: http://sci-hub.tw/10.1145/356635.356640 — это более поздняя статья от Кнута, где он пишет о том, что его опыт академического программирования не совсем применим к реальному миру. И что goto таки полезен, и приводит примеры этого (страница 287) и практически повторяет мои утверждения на стр. 294.
Sapienti sat!
Re: Code review (просмотр кода)
От: Kaifa Россия  
Дата: 01.05.19 08:04
Оценка:
RF>В чём заключается code review? Есть ли у вас на работе такое и как часто, каким образом оно проводится? Кто проводит у вас code review?
RF>Что бывает в случае плохого результата code review?

мне куда более интересно зачем нужен скрум, эджайл и канбан. а. еше 5с и абс забыл.

п.с. а кодревью штука полезная. зачастую новый работник может сгенерить код, исправляющий ошибку в одном блоке и из-за этого исправления рушится нахрен все остальное. и не из бандитских намерений, а просто потому, что он еще не знает как функционирует система в комплексе. тупо не знает бизнес процессы.
Re[12]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 01.05.19 15:43
Оценка:
LVV>>Ни for, ни while не являются замаскированными goto.
C>Да ну? А если дизассемблером посмотреть?
А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?
А давай еще разложим команды ассемблера на микрокоманды? Если уж спускаться внутрь — то спускаться до микросхем...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[13]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 01.05.19 17:44
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Ни for, ни while не являются замаскированными goto.

C>>Да ну? А если дизассемблером посмотреть?
LVV>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?
А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер.
Sapienti sat!
Re[10]: Code review (просмотр кода)
От: pagid Россия  
Дата: 01.05.19 21:30
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Ключевые люди там, в основном, все взрослые и уже отметившиеся в более других общеизвестных проектах

Угу, как раз из тех, что считают свой стиль единственно верным.
Re[13]: Code review (просмотр кода)
От: Privalov  
Дата: 02.05.19 06:30
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?


Я не очень понимаю, зачем опускаться на уровень ассемблерных команд. Ты всегда, компилируя проект, создаешь и ассемблерные листинги. Чтобы почитать на досуге? Мне за всю жизнь пришлось их читать несколько раз. Править — никогда.

О командах. ЕМНИП, команды цикла и перехода в самом деле разные. Но команда цикла, которая loop, работает со счетчиком. Команды для цикла типа while я не помню. Обычно делается проверка условия, и по результатам либо безусловный переход вверх, либо условный вниз.

Совсем оффтоп. А зато jmp и ret, по сути, одно и то же. И call где-то там же.
Отредактировано 02.05.2019 6:58 Privalov . Предыдущая версия .
Re[14]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 02.05.19 08:01
Оценка:
LVV>>>>Ни for, ни while не являются замаскированными goto.
C>>>Да ну? А если дизассемблером посмотреть?
LVV>>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?
C>А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер.
Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[15]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 02.05.19 16:16
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>>>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?

C>>А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер.
LVV>Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto
Как только начинаются вложенные циклы с выходом по флагу — goto предоставляет намного более высокий уровень.
Sapienti sat!
Re[16]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 02.05.19 17:41
Оценка:
LVV>>>>А если вспомнить, что команда цикла и команда безусловного перехода — это разные команды?
C>>>А ты посмотри сам. Возьми типичный код Линукса с "goto cleanup" и загляни в ассемблер.
LVV>>Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto
C>Как только начинаются вложенные циклы с выходом по флагу — goto предоставляет намного более высокий уровень.
Для этого есть break — более высокого уровня в силу обязательного ограничения выхода вниз, а не в произвольное место.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[17]: Code review (просмотр кода)
От: Cyberax Марс  
Дата: 02.05.19 19:08
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Зачем. С циклами я работаю на более высоком уровне абстракции, чем с if+goto

C>>Как только начинаются вложенные циклы с выходом по флагу — goto предоставляет намного более высокий уровень.
LVV>Для этого есть break — более высокого уровня в силу обязательного ограничения выхода вниз, а не в произвольное место.
Выделено.
Sapienti sat!
Re[8]: Code review (просмотр кода)
От: B0FEE664  
Дата: 03.05.19 11:05
Оценка: -1
Здравствуйте, Pzz, Вы писали:

Pzz>Вот чем хорош язык Go, в нем есть один единственный правильный стиль, который жестко енфорсится редактором текстов. И это сразу снимает все вопросы по стилю. И очень освобождает руки от форматирования текста.


И этот стить конечно обоснован статистическими исследованиями?
...
А, нет. Стиль не обоснован. Ерунда, значит.
И каждый день — без права на ошибку...
Re[7]: Code review (просмотр кода)
От: B0FEE664  
Дата: 03.05.19 11:18
Оценка:
Здравствуйте, Lexey, Вы писали:

L>P.S. А ТС случаем не жирный тролль? Что-то не верится с существование программиста с таким незамутненным сознанием.


Это далеко не худший образчик кода. Бывает много, много хуже...
И каждый день — без права на ошибку...
Re[9]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.05.19 13:12
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>И этот стить конечно обоснован статистическими исследованиями?


Ну, одним людям надо программы писать, а другим — стили обследовать...
Re[10]: Code review (просмотр кода)
От: B0FEE664  
Дата: 03.05.19 16:09
Оценка:
Здравствуйте, Pzz, Вы писали:

BFE>>И этот стить конечно обоснован статистическими исследованиями?

Pzz>Ну, одним людям надо программы писать, а другим — стили обследовать...

Хороший стиль уменьшает количество багов и увеличивает производительность труда.
И каждый день — без права на ошибку...
Re[11]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.05.19 18:17
Оценка: +1 -1 :)
Здравствуйте, B0FEE664, Вы писали:

BFE>>>И этот стить конечно обоснован статистическими исследованиями?

Pzz>>Ну, одним людям надо программы писать, а другим — стили обследовать...

BFE>Хороший стиль уменьшает количество багов и увеличивает производительность труда.


Угу. Только при командной разработке все вынуждены использовать не свой личный стиль, а стиль, кем-то выбранный в качестве командного. А если все равно стиль в большинстве случаев выбирает кто-то, а не сам разработчик, то почему бы этим кем-то и не быть Робом Пайком? Его стиль не хуже любого другого, но при этом его использование снимает всякие дискуссии о стилях.
Re[6]: Code review (просмотр кода)
От: RussianFellow Россия http://russianfellow.livejournal.com
Дата: 06.05.19 06:31
Оценка: :))
Здравствуйте, so5team, Вы писали:

S>Здравствуйте, RussianFellow, Вы писали:


RF>>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.


S>Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно, без выходных и проходных.


Что не так в этом коде?
1613 г. = 2024 г.
Re[8]: Code review (просмотр кода)
От: RussianFellow Россия http://russianfellow.livejournal.com
Дата: 06.05.19 06:38
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, Lexey, Вы писали:


L>>P.S. А ТС случаем не жирный тролль? Что-то не верится с существование программиста с таким незамутненным сознанием.


BFE>Это далеко не худший образчик кода. Бывает много, много хуже...


Плюсую!

Имел дело как-то с кодом, в котором не было комментариев, не было пробелов, порядок расстановки строк не соблюдался, порядок расстановки фигурных скобок не соблюдался, на одной строке писалось по несколько действий--приходилось долго сидеть над этим кодом, чтобы понять, что же он делает.
1613 г. = 2024 г.
Re[7]: Code review (просмотр кода)
От: so5team https://stiffstream.com
Дата: 06.05.19 07:06
Оценка: +3
Здравствуйте, RussianFellow, Вы писали:

S>>Ибо в команде у более-менее вменяемого руководителя вы бы рефакторингом подобных творений
Автор: RussianFellow
Дата: 11.04.19
занимались бы безостановочно, без выходных и проходных.


RF>Что не так в этом коде?


ДНК автора

Поскольку вы настолько не внимательны, что не можете обнаружить подсказки даже в тексте, из которого сами же делаете цитату, а именно:

Начиная с азов: с правил именования сущностей, с декомпозиции данных, с декомпозиции функций и т.д.

то обучение вас чему-либо выглядит бесполезной тратой времени.
Re[9]: Code review (просмотр кода)
От: Anonymous123 Чехия  
Дата: 06.05.19 07:52
Оценка:
Здравствуйте, RussianFellow, Вы писали:

RF>Здравствуйте, B0FEE664, Вы писали:


BFE>>Здравствуйте, Lexey, Вы писали:


L>>>P.S. А ТС случаем не жирный тролль? Что-то не верится с существование программиста с таким незамутненным сознанием.


BFE>>Это далеко не худший образчик кода. Бывает много, много хуже...


RF>Плюсую!


RF>Имел дело как-то с кодом, в котором не было комментариев, не было пробелов, порядок расстановки строк не соблюдался, порядок расстановки фигурных скобок не соблюдался, на одной строке писалось по несколько действий--приходилось долго сидеть над этим кодом, чтобы понять, что же он делает.


И в Visual Studio, и в Visual Studio Code есть автоматическое форматирование кода и даже есть комбинация клавиш для его запуска.
Re[8]: Code review (просмотр кода)
От: RussianFellow Россия http://russianfellow.livejournal.com
Дата: 06.05.19 08:26
Оценка: -1 :)
Здравствуйте, so5team, Вы писали:

S>

с правил именования сущностей, с декомпозиции данных, с декомпозиции функций


Понятия не имею, что это такое.
1613 г. = 2024 г.
Re[9]: Code review (просмотр кода)
От: so5team https://stiffstream.com
Дата: 06.05.19 08:53
Оценка: +1
Здравствуйте, RussianFellow, Вы писали:

S>>

с правил именования сущностей, с декомпозиции данных, с декомпозиции функций


RF>Понятия не имею, что это такое.


Вот уж удивили! Ну кто бы мог подумать?
Re[9]: Code review (просмотр кода)
От: LuciferNovoros Россия  
Дата: 06.05.19 10:22
Оценка:
Здравствуйте, RussianFellow, Вы писали:

S>>

с правил именования сущностей, с декомпозиции данных, с декомпозиции функций

RF>Понятия не имею, что это такое.

OMG...
Re[12]: Code review (просмотр кода)
От: B0FEE664  
Дата: 06.05.19 11:43
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz> Его стиль не хуже любого другого, но при этом его использование снимает всякие дискуссии о стилях.


Я правильно понимаю, что согласно этому стилю открывающая скобка находится не в том же столбце, что и закрывающая?
И каждый день — без права на ошибку...
Re[9]: Code review (просмотр кода)
От: B0FEE664  
Дата: 06.05.19 11:46
Оценка:
Здравствуйте, RussianFellow, Вы писали:

RF>Имел дело как-то с кодом, в котором не было комментариев, не было пробелов, порядок расстановки строк не соблюдался, порядок расстановки фигурных скобок не соблюдался, на одной строке писалось по несколько действий--приходилось долго сидеть над этим кодом, чтобы понять, что же он делает.


И это далеко не самое худшее. Хуже всего, когда в коде есть ошибки и при этом есть неявные зависимости в коде.
И каждый день — без права на ошибку...
Re[8]: Code review (просмотр кода)
От: B0FEE664  
Дата: 06.05.19 11:49
Оценка:
Здравствуйте, so5team, Вы писали:

RF>>Что не так в этом коде?

Например, из имени
CButton m_IDC_BUTTON3;
не видно, что эта кнопка делает.
И каждый день — без права на ошибку...
Re[13]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 06.05.19 12:34
Оценка:
Здравствуйте, B0FEE664, Вы писали:

Pzz>> Его стиль не хуже любого другого, но при этом его использование снимает всякие дискуссии о стилях.


BFE>Я правильно понимаю, что согласно этому стилю открывающая скобка находится не в том же столбце, что и закрывающая?


Посмотри сам. Все программы на Go сформатированны одинаково

И да, меня самого этот стиль бесит. Вернее, бесил два дня. Потом я привык
Re[11]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 06.05.19 12:55
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Ключевое: "на основе". Не часть компилятора, а отдельная утилита. На секундочку, настраиваемая.

S>А не так как у goвноавторов — стиль прибит гвоздями к компилятору.

Стиль не прибит гвоздями к компилятору.
Re[8]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 06.05.19 12:57
Оценка: :))) :)
Здравствуйте, LaptevVV, Вы писали:

LVV>В свое время, лет 20 назад, наш тогдашний завкаф сказала: Лаптева клонировать надо.


Она, похоже, лично хотела твоим клонированием заняться. А ты намека-то не понял...
Re[7]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 06.05.19 12:58
Оценка:
Здравствуйте, Эйнсток Файр, Вы писали:

LVV>>Я один могу преподавать всю программерскую и математическую часть учебного плана.


ЭФ>А процессор голыми руками в чистом поле из песка изготовить сможете, или нехватает практических навыков?


Россия — это вам не Калифорния и не Израиль. Тут земля черная, плодородная, нет полей из чистого песка.
Re[5]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 06.05.19 13:04
Оценка: 12 (1) :)
Здравствуйте, RussianFellow, Вы писали:

RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.


Затем, что если из живой, развивающейся, программы дерьмо время от времени не откачивать, то его накопится столько, что в нем все потонет.
Re[9]: Code review (просмотр кода)
От: Pzz Россия https://github.com/alexpevzner
Дата: 06.05.19 13:09
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Основная мысль состоит в том, что такой код (напичканный goto)


Ключевое слово тут "напичканный".

LVV>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход.

LVV>Это значительно упрощает как чтение, так и модификацию.

Ты понимаешь, что ты сейчас выступил против исключений и return из середины функции? Впрочем, Дейкстра бы с тобой согласился
Re[10]: Code review (просмотр кода)
От: LaptevVV Россия  
Дата: 06.05.19 15:00
Оценка:
LVV>>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход.
LVV>>Это значительно упрощает как чтение, так и модификацию.
Pzz>Ты понимаешь, что ты сейчас выступил против исключений и return из середины функции? Впрочем, Дейкстра бы с тобой согласился
Да, мы с ним ОДНОЙ крови...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[8]: Code review (просмотр кода)
От: Privalov  
Дата: 07.05.19 13:36
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Россия — это вам не Калифорния и не Израиль. Тут земля черная, плодородная, нет полей из чистого песка.


На Сахалине есть подходящий песок.
Re[7]: Code review (просмотр кода)
От: Privalov  
Дата: 07.05.19 13:53
Оценка:
Здравствуйте, RussianFellow, Вы писали:

RF>Что не так в этом коде?


Примерно всё.
С ходу вопрос: что такое MyStruct?
За что отвечает кнопка m_IDC_BUTTON4?

Если задача числодробительная, у нас было принято в программе указывать, откуда взят алгоритм расчетов.
Re[9]: Code review (просмотр кода)
От: Ночной Смотрящий Россия  
Дата: 07.05.19 20:11
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Структурное программирование хорошо тем, что каждая конструкция имеет ОДИН вход и ОДИН выход.


Ничего подобного структурное программирование не требует.

LVV>Это значительно упрощает как чтение, так и модификацию.


Усложняет чтение такая идея. Потому что при избавлении от выходов увеличивается вложенность.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Code review (просмотр кода)
От: SkyKnight Швейцария https://github.com/dmitrigrigoriev/
Дата: 09.05.19 07:58
Оценка: 5 (1)
Здравствуйте, RussianFellow, Вы писали:

RF>Зачем нужен рефакторинг? Я всю жизнь без всякого рефакторинга программировал.

Хотя бы за тем, чтобы бюджет проекта не проваливался.

1. Найти ошибку на стадии программирования (самим программистом) для проекта стоит мало.
2. Найти ошибку на стадии code review, стоит чуть дороже
3. Найти ошибку на стадии тестирования стоит еще дороже (ибо время тестера, потом время программиста и время code review)
4. Найти ошибку в продакшене может стоить очень много, плюс потеря доверия клиента.

Как пример у нас есть отдел, которые работает с аэропортами, так вот нашлась ошибка, к сожалению уже в продакшене, из-за которой в Дюссельдорфе а в аэропорту около 50 тыс чемоданов не выехали.
Аэропорт потом развозил эти чемоданы на такси, а счет выставил нашей конторе плюс всякую фигню еще. В общем ошибка обошлась конторе примерно в 100 тыс евро.
Попадись она на стадии ревью или тестирования затраты на ее устранение были бы ничтожно малы по сравнению с этой суммой.
github.com/dmitrigrigoriev/
Re[6]: Code review (просмотр кода)
От: DenisCh Россия  
Дата: 11.05.19 15:37
Оценка:
Здравствуйте, so5team, Вы писали:

s> подобных творений
Автор: RussianFellow
Дата: 11.04.19


Ну и как я теперь по ночам спать буду? Ты злостный вредитель...
[url=https://github.com/abbat/avalon1.0.449[/url]
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.