- Неправильное разделение на классы (в одни запихнуто куча разного, в других одна функция, которую можно было присоединить к другому классу)
- Отсутствие комментариев
- Гигантские функции на 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, то понятные названия становятся не такими уж понятными.
Наверное я об этом отдельную статью напишу.