— Неправильное разделение на классы (в одни запихнуто куча разного, в других одна функция, которую можно было присоединить к другому классу)
— Отсутствие комментариев
— Гигантские функции на 20 экранов
— Куча глобальных и статических переменных
— Отсутствие разумных интерфейсов и всяческое другое притеснение encapsulation
— Исходные файл в многие тысячи строк и сотни килобайт
Ух… поубивал бы…
P.S. Я еще забыл — отсутствие единообразия по любому выбранному критерию и дублирование (хотя иногда оно три- или четверолирование) кода.
А имена методов из 8 слов? )
Ну это хоть решается глобальной подменой.
А еще многократное дублирование кода. Я встречал проекты, в которых было по 5-6 файлов с одинаковыми классами/наборами функций.
Пропустил. Сейчас допишу.
Любой проект, на котором работает больше одного программиста (или любой большой проект) имеет такой код.
Это норма больших проектов и это работает.
Сомневаюсь, что по-другому может работать.
Но буду рад в этом разубедиться если покажите хотя бы один «хороший» проект.
Разница состоит в том что один проект «имеет такой код», другой проект «полностью состоит из такого кода».
Это работает частично. Да, проекты живут и движутся вперед. Но исправление ошибок и внесение изменения становится в десятки (если не сотни) раз дороже.
Как пример, можете глянуть код здесь — http://www.openscenegraph.org/projects/osg/wiki/Downloads
Хороших проектов действительно меньшинство, но они таки есть.
Your spam filter ate my comment 🙁
Really?
Да, реально сожрал мой камент.
Ну или ты забанил для защиты своей точки зрения 😉
Хм… По моему такое бывает с openid. Буду благодарен услышать альтернативные точки зрения, если не лень еще раз набрать коммент.
Лень конечно. Но что ради тебя не сделаешь, зря что ли в общаге пили 🙂
Значит так, в кратце и по опыту свой работы. Когда я жил в Украине — я тоже считал всё подряд говнокодом, индуским, китайским, все вокруг пида*асы а я один Д’артаньян.
Но прошло время, я посторел и пришел к выводу что праааавильного кода не бывает. Не потому, что это сделать невозможно — а потому что в таком случае проект не выживает. На поддятжу, корректировку и доводку нужно время, сделовательно деньги и отставание от конкурентов.
Можно писать красивый код — но проект скорее всего дохлый. Или not-for-profit. Для реальных же проектов этого не бывает.
Посмотри к примеру на ту же Toyota. Казалась бы — идеальная компания, на неё моляться, супер качество и всё такое. А педальки заедать стали… И не потому, что они плохие, злые или ещё что — просто жизнь такая.
Так, осталось выяснить, какой из двух Андреев с которыми пили 😉
Требую фамилию в студию 🙂
Насчет правильного кода… По разному оно бывает. Есть компании которые построены на плохом коде (особенно те в которые влили много денег). С другой стороны есть компании, которые развивали органично (не беря инвестиций) и обычно в них дело обстоит получше с кодом.
Я понимаю в чем плюсы плохого кода и плохих программисстов (даже когда-то писал это в программистском синхрофазатроне). Но, это не отменяет то, что я испытываю отвращение копаясь в нем и то, что меня бесит когда хорошие программисты пишут плохой код. Собственно меня бесит это из-за того, что я знаю, что писать хороший код занимает меньше времени, чем написание плохого для них (даже в краткосрочной перспективе).
К сожалению «органично» развиваться компании практически не могут с такой глобализацией. Т.е. развиваться ты можешь — но прошли те времена, когда можно было самому построить завод Форда или компанию Дисней. Корпорации развиваються по другому пути и под себя много чего подминают. В IT ситуация ещё более делекатная: сайт написать можешь сам, но шансы на развитие нулевые. (и не нужно приводить в пример «а вот есть (Amazon, ebay, …) сами всё сделали» — на каждый амазон приходиться 10 000 проваленых стартапов, с не менее толковыми ребятами, но без такого количества денег/удачи/…)
Я понимаю, что тебя это бесит. Та же фигня. Я не могу без слёз смотреть на то, что моя команда делает. Особенно интелектуалы из Сингапура. Но уволить всех нафик и набрать нормальных ребят (хотя бы с Польши) мне не кто не даст ни денег ни времени.
Это как Китайский ширпотреб — все знают что качество плохое, но все покупают: да, плохо, но дёшево. Да, носится год а не 5, но сейчас нет денег — я после куплю что-то толковое.
Так что — можно писать хороший код, развиваться органично и правильно — такие компании есть, но них никто не знает (слышал например про PragmaSoft? А твои коллеги?). Хочешь быстро рости — добро пожалывать в мир стероидов.
извели за кучу ошибок, пишу с работы, русской раскладки нет — транслателировал через сайт.
В целом я с тобой согласен.
Развиваться органически удается очень немногим.
а) Небольшим компаниям находящимся в нишах
б) Кому-то просто везучему
Насчет 10000 проваленных стартапов… Тут собственно говоря, статистика будет похожа и не с неорганическим путем развития. Так что сравнение не совсем корректно. Но, я согласен, вероятность выживания с органическим развитием меньше, чем с «взяли бабки и заколбасили».
P.S. Про PragmaSoft само собой слышал 😉 Естественно никто их коллег не слышал.
Наличие комментариев потеряно.
А еще список всех антипаттернов, запахов и прочих классификаций.
Стандартный идеальный код включает в себя:
— Правильное разделение на классы (все распихано по классам, куча абстракций, обертки одна другую погоняют, всюду интерфейсы, адамперы, синглотоны)
— Тщательно откоментированный код (в начала файла — пространная простыня, перед каждой строчкой — комментарий)
— Многочисленные компактрые функции (функция больше десяти строк? — давайте разобъем её на две)
— Никаких глобальных и статических переменных (тазим ссылку на все с самого верху)
— Encapsulation в полный рост (куча абстракций, обертки одна другую погоняют, всюду интерфейсы, адамперы, синглотоны)
— Исходные файлы не превышающие 2 экранов (в идеале — одна функция — один файл).
🙂
:)))
Ну все таки, если человеку не нравится сгнившие огурцы — это еще не значит, что недозревшие будут супервкусными 🙂
Отличный доклад про говнокод — http://itc-exp.blogspot.com/2010/08/blog-post_21.html
С комментариями не согласен. Чем меньше комментариев тем больше шансов, что они что то значат. Мало кто эти комментарии обновляют. В 90% случаев можно заменить комментарий на функцию или переименовать переменную так, что бы она объясняла, что происходит в коде.
То, что вы написала — это самоисполняющееся предсказание.
Люди думаю «комментарии мало кто обновляет», поэтому не имеет их смысла писать.
Я в последние 4-5 лет всегда пытаюсь комментировать сложные места в коде и интерфейсы. Как мне кажется достаточно полезно Например возвращаясь в код через 3 месяца, мне не надо ломать голову зачем я сделал что-то и пытаться вспомнить какую ошибку я обходил специальным куском кода.
«ReplyTo» так и будет писать post?
…Комментарии комментариям рознь, одно дело весь код покрыть комментариями (например в стиле «здесь мы прибавим единицу», тексты песен или дату смерти Бетховена), другое написать в 1-3 местах описание нетривиальных алгоритмом/хаков. Последнее будет скорее «нет комментариев» (за примерами на ohloh).
ReplyTo: В email’ах? Я гляну.
На самом деле второе для меня как раз «есть нужные комменарии».
«Нет коментариев» — это файл на 5000 строк, который делает тут непонятной функциональности, разбитой на три функции:
Run()
RunStep1()
RunStep2()
и не имеющий буквально ни одного комментария, что и зачем там делается.
В емейлах.
А с другой стороны что лучше 5000 строк в 3х функциях и комментарий поясняющий эти 5000 строк или эти 5000 и куча функций с понятными именами и ни одного комментария?
Я за второе 🙂
Все за второе, только почему-то я в большинстве кода вижу именно первое.
Плюс, указанный выбор хорош, когда кода на руках 30Kb. А когда кода на руках 30Mb, то понятные названия становятся не такими уж понятными.
Наверное я об этом отдельную статью напишу.