Как вы считаете, что будет с программированием в недалеком-далеком будущем?
Классический пример - из глубоко вложенного цикла надо резко вывалиться наружу.
Андрей, я вот из цикла про баранов вывалился.😃
Или вывалили…
Андрей, я вот из цикла про баранов вывалился
да, с баранами и дворниками (на лобовом стекле?) там было мощно задвинуто…
Еще б немного - и в бесконечный цикл впало )))
мощно задвинуто…
тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”.
Да, имелось ввиду это самое. 😃
Тогда действительно можно вывалиться через return. Но можно и огрести проблемы с параметрами, если их много. Однозначного решения нет и goto остаётся допустимым.
На самом деле тут ситуация несколько тоньше и глубже: если внезапно получается аномальное нагромождение вложенных циклов (аналогично - с большим нагромождением вложенных условий) - то примерно в ~70% случаев стоит задуматься о целесообразности реализуемого таким способом алгоритма. Чтобы в итоге раскидать эту кучу на несколько последовательных или даже вовсе не связанных блоков.
И это бывает в самых разных конкретных задачах.
если внезапно получается аномальное нагромождение вложенных циклов
да не надо “аномально”…
Достаточно иметь всего 4 вложенных цикла и выход из самого внутреннего внутрь внешнего. Потребуются либо if c дополнительной переменной и break, либо goto. Самый тривиальный пример.
речь идет не об “описании”, а о самодокументировании кода. Это совсем другое. (Хотя, общее описание, конечно, тоже нужно)
“выявлять” обычно ничего не требуется. Всё видно при беглом просмотре. В свое время существовал даже хороший принцип: “код любой функции не должен занимать больше одной страницы”. Не всегда удаётся ему буквально следовать, но стремится к этому полезно.
для проверки работы кода существует альфа и бета-тестирование. Если его результаты удовлетворительны при условии, что исходники оформлены в соответствии с требованиями и не вызывают вопросов - код принимается. При этом, не так важно, предпочитает программист использовать конструкции “for” или “while” - это его личное дело. Но, например, большое количество “goto” сразу вызывает сомнения ))
Львиная доля говнокода вытекает от: не предусмотрел, забыл, переполнил и забыл обнулить, забыл предусмотреть и т.п.
Ни альфа, ни бета тестирование это не выявят, если это не будет у программера в бошке зашито.
Давно это было, но на заре становления посещал Индийские софтверные гиганты с уровнем 6 сигм по многим классификациям. Так вот, чтобы добиться 6-ки, на одного ишачка кодера, приходилось до 4 проверяющих его код. И это только проверяющих именно код.
А была куча просто сотрудников, которые подготавливали “почву” для кодера, ну и потом все, согласно жизненного цикла.
И это в Индии - откуда ноги берёт добрые 70% именно говнокода.
Так что, реально, ни один руководитель не может отследить и не дать писать говнокод.
Львиная доля говнокода вытекает от: не предусмотрел, забыл, переполнил и забыл обнулить, забыл предусмотреть и т.п.
Так это целая наука. Грамотно спланировать структуру проекта, чтобы не пришлось ни в одной месте не вставлять потом костыли (т.е. чтобы структура сразу учитывала ВСЕ, что потом будет в проекте), а после этого грамотного планирования (с первого раза никогда не получается, особенно если задача - нова для программиста) - попробовать сделать невероятное: обеспечить вменяемые сроки разработки этого грамотно структурированного монстра 😈
Умные могут сказать: учите паттерны проектирования и т.д., но без конкретного практического опыта толку от этого будет не много. Пока сам лично как следует не влипнешь по колено - не поймешь.
Ну и без умения заворачивать в красивую обертку - никуда! 😈 Можно пол жизни учиться писать идеальный код и никогда не научиться, а умение заворачивать и прикручивать свистелки-перделки - позволяет начать продавать свой труд как можно раньше и начать получать деньги.
Возможно ли так организовать процесс, чтобы поддержка на уровне исходного кода не требовалась бы никогда, и соответственно никто бы никогда не мог узнать говнокод там внутри или нет. Например, когда мы отдаем автомашину в мастерскую на ремонт, то там у работников не возникает вопрос хорошо ли спроектирован насос: он либо работает либо нет; в последнем случае его меняют на другой. И никто в него не лезет чтобы понять говнонасос это или нет. (Завод-производитель конечно все равно будет вынужден копаться во внутренностях; я тут рассматриваю самого производителя насосов как одно “лицо”. Если программист написал такой код в котором сам не может разобраться, то это уже его внутренние проблемы)
И никто в него не лезет чтобы понять говнонасос это или нет…
Попрошу не впутывать говнонасосы в ваши гнилые программерские разборки 😃 Говнонасосы или фекальные (они-же - канализационные) насосы - это высший уровень насосостроения 😃 и далеко не всякая насосная фирма может позволить себе их выпуск: www.sololift-sololift.ru/grundfos_sololift.php 😃
Возможно ли так организовать процесс, чтобы поддержка на уровне исходного кода не требовалась бы никогда, и соответственно никто бы никогда не мог узнать говнокод там внутри или нет
только для очень маленьких и компактных программ.
“Во всякой большой программе есть как минимум 3 ошибки. Когда их устраняют, обнаруживаются/привносятся следующие 3 и т.д. В дальнейшем этот процесс может продолжаться до бесконечности” - народная мудрость.
На самом деле наибольшие неприятности доставляют не ошибки кодирования алгоритмов - подавляющее большинство их обычно так или иначе выявляются на этапах альфа и бета-тестирования, а отсутствие проверок граничных значений параметров. За счёт существования таких ошибок появляются трудно диагностируемые сбои и, что самое неприятное, осуществляются взломы.
И еще: я не очень хорошо понимаю, что участники дискуссии понимают под словом “говнокод”.
Если программа прошла приемку по структуризации, оформлению, объему памяти, времени выполнения и альфа+бета тестированию, то код является рабочим. Ситуация, когда “сам программист не может разобраться в том, что он написал”, должна исключаться на этапе проверки структуризации и оформления.
Если кто-то считает, что каждая строка написанного кода должна контролироваться “проверяющими”, то на мой взгляд - это абсурд. Бессмысленная растрата человеческого времени и людских ресурсов.
Для того, чтобы исходник был формально принят, он должен быть в таком состоянии, чтобы другой программист соотв. квалификации мог в нем разобраться и, при необходимости, что-то модифицировать. Всё остальное выявляется при тестировании.
Попрошу не впутывать говнонасосы…
Искренне прошу меня извинить… не учел что тут могут быть специалисты по разным приборам…)))
И еще: я не очень хорошо понимаю, что участники дискуссии понимают под словом “говнокод”.
Вот-вот. Мне кажется что “неучет граничных условий” это не говнокод. Последнее - это по-моему когда ни любой проверяющий (ни сам программист через неделю) глядя на код не может понять WTF!
Я думаю, что надо разделять 2 различных ситуации:
- когда люди пишут “сами для себя”
- когда производится “промышленное” производство программ
В первом случае, неопытные программисты действительно могут производить большие куски запутанного кода, в котором сам черт ногу сломит. Но в случае промышленного производства такая ситуация должна быть автоматически исключена при приемке исходников.
В моем понимании говнокод - это когда задача решается либо явно не оптимальным способом (банальная сортировка пузырьком при отсутствии ограничений в памяти), не учитывает возможности конкретного языка (грубо говоря, когда школьник в своей программе заводит два десятка однотипных переменных вместо массива 😃), либо когда решение является костылем, да еще и неаккуратным (“если он пасть закроет - у него на ж0пе кожа лопнет” 😃).
заводит два десятка однотипных переменных вместо массива
не понял. Массивы нужны в тех случаях, когда нужна индексация. Если индексация не нужна, то простые переменные работают всегда (!) эффективней.
сортировка пузырьком при отсутствии ограничений в памяти
- обычно если есть ОС и библиотеки, то самому сортировку писать не требуется
- если “пузырёк” не вылезает из временнЫх ограничений - наплевать.
если он пасть закроет - у него на ж0пе кожа лопнет
вообще не понял.
На мой взгляд, плохой исходный код - запутанный, необозримый (большой и одним куском), плохо структурированный и плохо самодокументированный.
Еще раз: условия по памяти, скорости и ошибкам алгоритмов - другие этапы проверки.
Наверное, здесь тоже есть смысл ввести 2 градации:
- качество самого исходного кода (“понятность” и “понимаемость другими”)
- качество реализации алгоритмов (память, скорость, ошибки)
Не надо всё валить в одну кучу.
Я думаю, что надо разделять 2 различных ситуации: 1) когда люди пишут “сами для себя” 2) когда производится “промышленное” производство программ
Я предполагал именно промышленное окружение. (Если сам для себя пишешь, то что написал то и с’ел - сам себе хозяин и судья; и свое врядли кто назовет меньше чем гениальный код…))).
Мне кажется, что как ни странно, как раз в промышленных продуктах и присутствует много этого самого. Видимо приемщику главное что бы работало (пусть как-то, пусть сейчас…). Еще раз, в моем понимании говнокод -это когда квалифицированный программист смотрит на код и не может понять что это и зачем, как когда мы смотрим на помойку. Если логика ясна, но написано не оптимально, и не все учтено,то такого программиста еще можно спасти.))
П.С. я не профессиональный программист, так что это все мои гнусные домыслы)) ; с др. стороны, много общался с программистами))
вообще не понял.
Видимо приемщику главное что бы работало (пусть как-то, пусть сейчас…).
ну еж-тыть… Приёмка - это СОВСЕМ не один этап!!!
На этапе приёмки ИСХОДНИКОВ ни о каком “работало/не работало” речь еще не идёт. Оценка производится по принципу “кто ясно мыслит - тот ясно излагает”
то простые переменные работают всегда (!) эффективней.
Бывают графические процессоры. Которые заточены под перемножение матриц и т.д. Простые переменные будут ячейками внутри массива и индивидуальная работа с ними будет значительно медленнее, чем валовая обработка данных.
Можно еще много примеров привести, да и опять-же - зачастую массивы применяются не для быстродействия, а для удобоваримости и расширяемости кода.
… не вылезает из временнЫх ограничений - наплевать…
Го8нокод - это не тот код, который не работает или глючит. А тот, который нарушает читаемость и\или расширяемость проекта или как либо еще демонстрирует невысокий уровень человека, который его написал.
Вот как-то так вот оно. 😃
Го8нокод - это не тот код, который не работает или глючит. А тот, который нарушает читаемость и\или расширяемость проекта или как либо еще демонстрирует невысокий уровень человека, который его написал.
вот это в самую точку! ))