В нашей вселенной я таких не видел. Ни одной. Всегда по ходу эксплуатации меняются какие-нибудь требования или вылезают дополнительные условия, которые не предусмотрены техзаданием. Иногда спустя пару-тройку лет интенсивной эксплуатации системы.
Мне иногда приходится править свой код, написанный несколько лет назад и давно забытый. Увидев его, я реагирую по-разному, от "О! Это мое!" до "Какой идиот это написал?" На чужой код я реагирую примерно так же, разумеется, про себя.
Один из лучших проектов, где я работал, был сделанн на очень древнем Бейсике. Читабельные программы на нем писать невозможно по определению. Имя переменной могла включать не более 2 символов, и второй, если был, то обязательно цифра. Ну и много чего еще. Так вот, команда сделала невозможное. Нам не было ни одной строчки макаронного кода. Практически не было глюков. Но все время требовалось что-нибудь поменять: количество выводимых разрядов, или какую-нибудь шкалу, да мало ли. Главное, постоянно. И в течение примерно 2 лет я справлялся с этим в одиночку.
И вот что я еще заметил. Хороший код стимулирует и дальше писать в таком же стиле. Как и плохой. И тот и другой код можно успешно сопровождать. Разница только в стоимости.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Но всему поводом (видимо, формальным) послужило неудовольствие господина моим кодом, который, увы-увы, работает, и работает без ошибок, но так тяжело доходит до сознания Крутого Манагера. По его уверениям, все тут массой мой код отвергли, признали "ужасным", подтвердили худшие его опасения и потому он свернул все мои наработки (делавшиеся на заказ отечественным фирмам), разорвал договоры и отправил меня восвояси искать другую работу (которой у нас не так легко найти).
Буду резок.
Не знаю, что вы со своим руководителем говорили друг другу, — возможно, даже орали и поняли друг друга превратно.
А вот что касается кода...
От кода требуется несколько вещей
— чтобы он работал в реальных условиях
— чтобы он работал предсказуемо и доказуемо
— чтобы было легко дорабатывать (исправлять, дополнять...)
— чтобы можно было передать коллегам
Тот образец кода, пусть и работающий, — по всем остальным параметрам никуда не годится.
Мастер плетения кружев из макарон может бить себя в грудь, мамой клясться, что всё там в порядке. Хорошо, тогда воспитай ещё нескольких учеников, способных разобраться и сопровождать такую писанину.
Если руководитель суёт нос в код сотрудника, это почему происходит?
— излишнее любопытство, желание всюду понадзирать?
— у него есть план ввести в курс дела новых сотрудников?
— в компании есть стандарты на стиль кодирования, их надо соблюдать?
— проблемы слишком далеко выползли, — например, сотрудник не справляется с потоком заявок на отладку-доработку; или коллеги видят код и неприлично кричат; или раз за разом ломаются коммиты в репозитории?
Почему мне кажется, что было именно последнее?
Касательно претензий про 200 строк.
Рефакторить можно так, что станет понятно, а можно "на отвяжись", — так, что минимизируется формальная оценочная функция "среднее количество строк на функцию".
Если твой рефакторинг оказался ещё менее удобочитаемым, чем исходные портянки, — это не значит, что надо считать портянки идеалом.
В конце концов, твой код читают четверо: ты, ты через полгода, компилятор и коллеги.
Ты можешь думать, что там всё хорошо.
Может быть, даже через полгода будешь так же думать.
Компилятору вообще глубоко пофиг.
Не пофиг коллегам, но ты их ставишь в такое положение, что им проще быть пофиг, чем связываться.
Только не думай, что это какой-то твой уникальный косяк. Такое случается со многими индивидуалистами.
Когда я работал электриком, то потратил определённые усилия, чтобы научить старшего коллегу делать так, чтобы было сразу понятно всем. В том числе, личным примером и помощью (до элементарного, ходил и маркировал всё, до чего дотянусь: клеммы, автоматы, розетки). Вроде достиг результатов.
В общем, — говорить за руководящие качества руководителя не буду, ни выгораживать, ни ругать (как бы тебе это ни хотелось). Для этого надо слишком основательно влезть в ваши разборки.
А за твои труды скажу одно: иди и больше не греши.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>..."Оцените качество кода"...
Разговор ни о чем.
Нужен другой код, который условно назовем "эталоном". Если нет эталона, этот код идеален в виду его единственности.
Есть более вырожденный случай — закрытый код. Закрытый код — это абсолют идеальности.
ЮЛ>Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках?
Идея такова, что хорошо бы держать функции в пределах 20 строк. Если же возникает вопрос, может ли код оставаться неплохим при 201, то ты делаешь что-то очень неправильно.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Здравствуйте, местные хакеры. ЮЛ>я здесь новый и не стал бы сюда заглядывать по своей нужде, но спровоцировал мой начальник. Бывший мой начальник, поскольку недавно уволил меня при очень странных обстоятельствах. Этот типчик вам здесь известен, это его тема "Оцените качество кода" http://rsdn.ru/forum/cpp/5787830.flat
висит у вас на форуме, и это он вызвал меня на этот форум, будучи уверен, что будто мне нечего будет возразить, и меня тут раздавят морально, так же как он раздавил уже материально.
ЮЛ>Потому что я прекрасно знаю о ком пишу. У меня в разное время были прекрасные товарищи, которых увольняли без причин. Один, например, сейчас работает в нижегородском Интеле. ЮЛ>Так вот с этим типом-ухарем отношения не сложились сразу. Товарищ много мнит о себе. Впрочем, начальник его в этом поощряет.
Твой рассказ говорит о том, что у вас все через одно место делается. Нет четких регламентов, что и когда делать, как коммитить и тд. Это недоработка менеджмента скорее всего, но и его понять можно, если учесть с какими людьми ему приходится работать каждый день
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Именно это я и хотел когда то сказать в отношении "Совершенного кода" Макконелла. Как альтернативу, я предложил бы написать книгу "Искусство написания несовершенного кода", которая оказалась бы еще полезнее. Но кто внимательно прочел МакКонелла, увидит, что в ней нет строгих формальных требований, это не катехизис программиста, а всего лишь сборник полезных приемов и интересных идей.
Ох и портянок ты написал тут по треду, сколько надменности. Не будь таким, это же фу-фу-фу.
Если ты внимательно читал Макконнелла (его фамилия правильно пишется так, ребятки), то возможно, что ты читал и главу №33, про личность программиста. Рекомендую.
33.4. Профессиональная честность
Становление высококвалифицированного программиста предполагает развитие обостренного чувства профессиональной честности, которая может проявляться в самых разных формах:
отказ от притязаний на роль эксперта, если вы им не являетесь; охотное признание собственных ошибок;
....
33.5. Общение и сотрудничество
По настоящему отличные программисты учатся эффективно сотрудничать, что всегда подразумевает написание удобочитаемого кода. Вероятно, компьютер читает вашу программу так же часто, как другие люди, но он читает плохой код гораздо лучше, чем люди. Работая над кодом, не забывайте про людей, которым придется изменять его в будущем. Программирование — это в первую очередь общение с другим программистом и только во вторую — с компьютером.
Понимаешь? Общение важнее кода, так что нужно поумерить своё эго, не считать себя умнее других и уважать людей, с которыми ты работаешь. Независимо от их должности, а также от того, умнее ты их в самом деле или нет.
Тогда и вопросов у тебя таких не будет ко всем, а у начальства и коллектива к тебе.
Код откровенное дерьмо. Компилируется, может даже решает свою задачу (хотя это спорно), но на этом его достоинства заканчиваются. А у кода много других обязанностей.
Впрочем бывает и хуже. Есть много проектов, написанных в таком стиле и приносящих доход владельцам. Но дорабатывая твой код я бы удовольствия не получил.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Задача была поначалу для интереса — найти алгоритм поиска замкнутых контуров из произвольно заданного набора кусков кривых. Теория графов по Эйлеру была руководящей идеей. Основным требованием для меня являлось сохранение линейной скорости алгоритма. ЮЛ>Если кто то считает, что задача очевидным образом формализуется в виде классов — прошу на сцену. Я же таких явных классов не видел, а создавать их искусственно, на потребу г-на начальника, считаю бесполезной и даже вредной тратой времени. Я могу сформулировать такой критерий — если классов не видно, то лучше никаких классов, чем что то уродливое, но объектно-ориентированное.
Я видел этот код утром, и даже не являясь специалистом в C++ я могу написать большое количество претензий к нему.
После объяснения того, что этот код делает, количество претензий у меня увеличится в разы. Если алгоритм нетривиален, то основные идеи должны быть описаны в комментариях, и этих комментариев должно быть очень много.
ЮЛ>Любопытный факт — код алгоритма этот Манагер выложил в интернет , заявив , что этот код ему нафиг не нужен, но когда при моем увольнении зашел разговор, чтобы отдать мне этот код для завершения работы с заказчиком, — как стоило узнать о пошлом скупердяйстве манагера, который вдруг заявил, что код — собственность фирмы. Что это как не шизофрения?
Деньги заплачены, работа сделана. Что заказчик делает с кодом — его личное дело, исполнителя не касается.
ЮЛ>Код я все же получил, хоть и без мелких примочек, и довел его до второй успешной реализации — на этот раз нам с заказчиком понадобилось найти алгоритм построения самого внешнего контура. И меня не сильно напрягала длина этого метода. Хотя новый алгоритм еще более разросся, но в нем заложена красивая идея, вот что важно, и эта внутренняя красота будет посовершенней дутой формальности.
Через 4 месяца у заказчика начинает вываливаться Access Violation в непонятном месте. Разбираться с кодом садится человек, который его видит впервые. Вот тут эти формальности начинают играть очень серьезную роль — будет ли проблема решена за несколько дней или за несколько недель.
ЮЛ>Понятен любому... дураку, хотите вы сказать? А что ему надо бы знать теорию графов и вообще хотеть разбираться в коде, это не в счет? А у нас сплошь и рядом за отладку и расширение садятся те, кто не в зуб ногой. Это и есть вид халтуры, а я почему то должен этому подмахивать, кладя всюду соломку в своем коде. ЮЛ>Я не против рефакторинга, если он действительно удачен и полезен для дела. Я против мелочных придирок и тупого невежества манагеров. Но рефакторинг, на мой взгляд, надо делать ПОСЛЕ написания алгоритма, и тем более не в ущерб простоте его написания.
..подмахивать.. ..тупого невежества.. . Глядя на тональность сообщений, не удивлюсь если что-то подобное было сказано в лицо и при свидетелях, после чего топикстартер и был уволен.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>И причин тут по меньшей мере две — 1)алгоритм не расползается по разным местам и файлам, а более менее локализован, что важно при его первичном моделировании, и 2)отладка не настолько утомительна, как в случае классов,
Я ни в той, ни в этой теме не участвовал и не собираюсь. Лишь скромно отмечу, что если свеженаписанному коду требуется отладка, то место этому коду все же на помоечьке (с). Для проверки функциональности и валидации кода в 20ХХ годах принято использовать более удобные, а главное, эффективные инструменты.
2)да еще с использованием STL-фичей, на ошибки которых компилятор ругается хорошо если 10-этажнвм матом (а чаще просто вываливает на экран половину системных h-файлов), а отладчики в половине случаев не способны показать значение зарытого в классах члена или свойства.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>>И причин тут по меньшей мере две — 1)алгоритм не расползается по разным местам и файлам, а более менее локализован, что важно при его первичном моделировании, и 2)отладка не настолько утомительна, как в случае классов, L>Я ни в той, ни в этой теме не участвовал и не собираюсь. Лишь скромно отмечу, что если свеженаписанному коду требуется отладка, то место этому коду все же на помоечьке (с). Для проверки функциональности и валидации кода в 20ХХ годах принято использовать более удобные, а главное, эффективные инструменты. L>
Слышу многа шума насчет эффективности инструментов 21 века, ну так назовите их. И заодно просветите, помогают ли они разработке или затягивают ее?
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Слышу многа шума насчет эффективности инструментов 21 века, ну так назовите их.
Просвещать имеет смысл только тех, кто просвещаться хочет, но вот дело в том, что их-то как раз просвещать не надо — они просвещаются сами. Я вот за топиком наблюдаю и конкретно у Вас ни желания просвещаться, ни желания быть просвещаемым не наблюдаю.
ЮЛ>И заодно просветите, помогают ли они разработке или затягивают ее?
Боюсь, что прежде чем переходить к обсуждению сроков, нам нужно будет сначала прояснить терминологию. А то у меня есть подозрения, что наше с Вами понимание термина "готово" весьма разница.
Здравствуйте, Klag, Вы писали:
K>Я видел этот код утром, и даже не являясь специалистом в C++ я могу написать большое количество претензий к нему. K>После объяснения того, что этот код делает, количество претензий у меня увеличится в разы. Если алгоритм нетривиален, то основные идеи должны быть описаны в комментариях, и этих комментариев должно быть очень много.
А вы не находите, что для "много-много комментариев" больше подходит учебное пособие? Или все таки я должен за бесплатно писать рядом с кодом еще и учебное пособие?
ЮЛ>>Любопытный факт — код алгоритма этот Манагер выложил в интернет , заявив , что этот код ему нафиг не нужен, но когда при моем увольнении зашел разговор, чтобы отдать мне этот код для завершения работы с заказчиком, — как стоило узнать о пошлом скупердяйстве манагера, который вдруг заявил, что код — собственность фирмы. Что это как не шизофрения? K>Деньги заплачены, работа сделана. Что заказчик делает с кодом — его личное дело, исполнителя не касается.
Вы кого называете заказчиком? Шефа фирмы — Крутого Манагера? Так этот "заказчик" дважды прерывал выполнение заказа, подставляя и фирму, и клиента. Не точнее ли назвать его не заказчиком, а посредником? причем негодным посредником.
K>Через 4 месяца у заказчика начинает вываливаться Access Violation в непонятном месте. Разбираться с кодом садится человек, который его видит впервые. Вот тут эти формальности начинают играть очень серьезную роль — будет ли проблема решена за несколько дней или за несколько недель.
А меня вы уже похоронили). Знаете, я не верю в чертовщину и Access Violation в непонятном месте.
Вообще интересно, в Майкрософте следуют вашим рекомендациям? Скажем, обнаружен баг в Винде. Берут первого попавшегося дурака, ни разу не видевшего код, и он за пять минут устраняет проблему.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>А вы не находите, что для "много-много комментариев" больше подходит учебное пособие? Или все таки я должен за бесплатно писать рядом с кодом еще и учебное пособие?
Суровые бородатые дядьки, писавшие на Фортране 4 для ЕС ЭВМ программы, в шапке практически всегда указывали, какие алгоритмы использовали, и давали ссылку на первоисточник – монографию или статьи в журналах. Это, замечу, на перфокартах. Иначе невозможно разобраться с матаном в коде. А код этот живет десятилетиями. Я с таким работал.
ЮЛ>Вы кого называете заказчиком? Шефа фирмы — Крутого Манагера?
Для Вас он – заказчик. Нет?
K>>Через 4 месяца у заказчика начинает вываливаться Access Violation в непонятном месте.
ЮЛ>А меня вы уже похоронили).
Ваш код в дальнейшем может попасть на сопровождение кого угодно. Вот если вас уволят, на коде можно ставить крест? Как я указывал выше, такой код может работать десятилетиями. Пример: Графор 1972 года рождения, числодробительные фортрановские библиотеки, банковский софт.
ЮЛ>Знаете, я не верю в чертовщину и Access Violation в непонятном месте.
И тем не менее, Access Violation может выскочить где угодно. Это не вопрос веры. Например:
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>А меня вы уже похоронили). Знаете, я не верю в чертовщину и Access Violation в непонятном месте.
В коде на пару порядков сложнее приведённого — вполне.
ЮЛ>Вообще интересно, в Майкрософте следуют вашим рекомендациям? Скажем, обнаружен баг в Винде. Берут первого попавшегося дурака, ни разу не видевшего код, и он за пять минут устраняет проблему.
1. Не юродствуйте. От пригодности кода к сопровождению не только его автором до исправления силами "первого попавшегося дурака" — "дистанции огромного размера".
2. В Microsoft очень даже активно комментируют исходники, и все тонкие моменты, на которые желательно обратить внимание при вхождении в контекст, там расписаны для будущих поколений (и для себя любимых через пару лет, естественно). У них есть проблемы, но они совсем не в этом месте.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Слышу многа шума насчет эффективности инструментов 21 века, ну так назовите их. И заодно просветите, помогают ли они разработке или затягивают ее?
Я сделаю вид, что не заметил сарказма, и отвечу по сути.
Инструменты — включают в себя как минимум: плотное тестирование (а иногда и приближение к идеальному TDD), BDD для соответствия внешним требованиям, статический анализ, использование кастомных типов и их проверка как в рантайме, так и при статическом анализе (для показательного примера — где-то нужен тип "целое, которое равно или -1, или от 100 до 159, или от 280 до 475, но не другие значения")...
И, как Вам должно быть известно из умных книг, цена ошибки при отладке считается в 10 раз больше, чем при разработке, а у пользователя в 10 раз больше, чем при отладке. Так что такие инструменты, естественно, помогают разработке (если считать результатом работающий код, а не сдать и забыть).
Если у Вас есть какие-то возражения к сказанному, то их имеет смысл высказывать без сарказма и без личных наездов на прошлых руководителей и прочих участников чего-либо. Наехать мы потом всегда успеем
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>А меня вы уже похоронили). Знаете, я не верю в чертовщину и Access Violation в непонятном месте. ЮЛ>Вообще интересно, в Майкрософте следуют вашим рекомендациям? Скажем, обнаружен баг в Винде. Берут первого попавшегося дурака, ни разу не видевшего код, и он за пять минут устраняет проблему.
Я ждал этого аргумента.
Вот вам кодинг стиль другой компании, которая разрабатывает кода не меньше MS. Google C++ Code Style
Советую прочесть и попробовать отревьюить свой код по его правилам.
Выделение жирным мое
Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer, since these conventions cover far more than just source file formatting.
One way in which we keep the code base manageable is by enforcing consistency. It is very important that any programmer be able to look at another's code and quickly understand it. Maintaining a uniform style and following conventions means that we can more easily use "pattern-matching" to infer what various symbols are and what invariants are true about them. Creating common, required idioms and patterns makes code much easier to understand. In some cases there might be good arguments for changing certain style rules, but we nonetheless keep things as they are in order to preserve consistency.
Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases we constrain, or even ban, use of certain features. We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted.
Процесс код ревью в гугле
Вкратце — каждый коммит должен быть проверен человеком, у которого есть т.н. readability. Readability показывает что человек может оценивать других людей, насколько их код соответствует гугловым стандартам и имеет особый процесс получения. Даже если все владельцы кода согласны с изменением, но нет readability аппрува, то система не даст закоммитить изменение.
p.s. Я не гуглер, но у меня есть java и javascript readability, поэтому я имею представление о чем говорю.
Перекуём баги на фичи!
