Как вы считаете, что будет с программированием в недалеком-далеком будущем?
Попрошу не впутывать говнонасосы…
Искренне прошу меня извинить… не учел что тут могут быть специалисты по разным приборам…)))
И еще: я не очень хорошо понимаю, что участники дискуссии понимают под словом “говнокод”.
Вот-вот. Мне кажется что “неучет граничных условий” это не говнокод. Последнее - это по-моему когда ни любой проверяющий (ни сам программист через неделю) глядя на код не может понять WTF!
Я думаю, что надо разделять 2 различных ситуации:
- когда люди пишут “сами для себя”
- когда производится “промышленное” производство программ
В первом случае, неопытные программисты действительно могут производить большие куски запутанного кода, в котором сам черт ногу сломит. Но в случае промышленного производства такая ситуация должна быть автоматически исключена при приемке исходников.
В моем понимании говнокод - это когда задача решается либо явно не оптимальным способом (банальная сортировка пузырьком при отсутствии ограничений в памяти), не учитывает возможности конкретного языка (грубо говоря, когда школьник в своей программе заводит два десятка однотипных переменных вместо массива 😃), либо когда решение является костылем, да еще и неаккуратным (“если он пасть закроет - у него на ж0пе кожа лопнет” 😃).
заводит два десятка однотипных переменных вместо массива
не понял. Массивы нужны в тех случаях, когда нужна индексация. Если индексация не нужна, то простые переменные работают всегда (!) эффективней.
сортировка пузырьком при отсутствии ограничений в памяти
- обычно если есть ОС и библиотеки, то самому сортировку писать не требуется
- если “пузырёк” не вылезает из временнЫх ограничений - наплевать.
если он пасть закроет - у него на ж0пе кожа лопнет
вообще не понял.
На мой взгляд, плохой исходный код - запутанный, необозримый (большой и одним куском), плохо структурированный и плохо самодокументированный.
Еще раз: условия по памяти, скорости и ошибкам алгоритмов - другие этапы проверки.
Наверное, здесь тоже есть смысл ввести 2 градации:
- качество самого исходного кода (“понятность” и “понимаемость другими”)
- качество реализации алгоритмов (память, скорость, ошибки)
Не надо всё валить в одну кучу.
Я думаю, что надо разделять 2 различных ситуации: 1) когда люди пишут “сами для себя” 2) когда производится “промышленное” производство программ
Я предполагал именно промышленное окружение. (Если сам для себя пишешь, то что написал то и с’ел - сам себе хозяин и судья; и свое врядли кто назовет меньше чем гениальный код…))).
Мне кажется, что как ни странно, как раз в промышленных продуктах и присутствует много этого самого. Видимо приемщику главное что бы работало (пусть как-то, пусть сейчас…). Еще раз, в моем понимании говнокод -это когда квалифицированный программист смотрит на код и не может понять что это и зачем, как когда мы смотрим на помойку. Если логика ясна, но написано не оптимально, и не все учтено,то такого программиста еще можно спасти.))
П.С. я не профессиональный программист, так что это все мои гнусные домыслы)) ; с др. стороны, много общался с программистами))
вообще не понял.
Видимо приемщику главное что бы работало (пусть как-то, пусть сейчас…).
ну еж-тыть… Приёмка - это СОВСЕМ не один этап!!!
На этапе приёмки ИСХОДНИКОВ ни о каком “работало/не работало” речь еще не идёт. Оценка производится по принципу “кто ясно мыслит - тот ясно излагает”
то простые переменные работают всегда (!) эффективней.
Бывают графические процессоры. Которые заточены под перемножение матриц и т.д. Простые переменные будут ячейками внутри массива и индивидуальная работа с ними будет значительно медленнее, чем валовая обработка данных.
Можно еще много примеров привести, да и опять-же - зачастую массивы применяются не для быстродействия, а для удобоваримости и расширяемости кода.
… не вылезает из временнЫх ограничений - наплевать…
Го8нокод - это не тот код, который не работает или глючит. А тот, который нарушает читаемость и\или расширяемость проекта или как либо еще демонстрирует невысокий уровень человека, который его написал.
Вот как-то так вот оно. 😃
Го8нокод - это не тот код, который не работает или глючит. А тот, который нарушает читаемость и\или расширяемость проекта или как либо еще демонстрирует невысокий уровень человека, который его написал.
вот это в самую точку! ))