Как вы считаете, что будет с программированием в недалеком-далеком будущем?

Пашеч
  1. речь идет не об “описании”, а о самодокументировании кода. Это совсем другое. (Хотя, общее описание, конечно, тоже нужно)

  2. “выявлять” обычно ничего не требуется. Всё видно при беглом просмотре. В свое время существовал даже хороший принцип: “код любой функции не должен занимать больше одной страницы”. Не всегда удаётся ему буквально следовать, но стремится к этому полезно.

  3. для проверки работы кода существует альфа и бета-тестирование. Если его результаты удовлетворительны при условии, что исходники оформлены в соответствии с требованиями и не вызывают вопросов - код принимается. При этом, не так важно, предпочитает программист использовать конструкции “for” или “while” - это его личное дело. Но, например, большое количество “goto” сразу вызывает сомнения ))

Львиная доля говнокода вытекает от: не предусмотрел, забыл, переполнил и забыл обнулить, забыл предусмотреть и т.п.
Ни альфа, ни бета тестирование это не выявят, если это не будет у программера в бошке зашито.
Давно это было, но на заре становления посещал Индийские софтверные гиганты с уровнем 6 сигм по многим классификациям. Так вот, чтобы добиться 6-ки, на одного ишачка кодера, приходилось до 4 проверяющих его код. И это только проверяющих именно код.
А была куча просто сотрудников, которые подготавливали “почву” для кодера, ну и потом все, согласно жизненного цикла.
И это в Индии - откуда ноги берёт добрые 70% именно говнокода.

Так что, реально, ни один руководитель не может отследить и не дать писать говнокод.

ADF

Львиная доля говнокода вытекает от: не предусмотрел, забыл, переполнил и забыл обнулить, забыл предусмотреть и т.п.

Так это целая наука. Грамотно спланировать структуру проекта, чтобы не пришлось ни в одной месте не вставлять потом костыли (т.е. чтобы структура сразу учитывала ВСЕ, что потом будет в проекте), а после этого грамотного планирования (с первого раза никогда не получается, особенно если задача - нова для программиста) - попробовать сделать невероятное: обеспечить вменяемые сроки разработки этого грамотно структурированного монстра 😈
Умные могут сказать: учите паттерны проектирования и т.д., но без конкретного практического опыта толку от этого будет не много. Пока сам лично как следует не влипнешь по колено - не поймешь.

Ну и без умения заворачивать в красивую обертку - никуда! 😈 Можно пол жизни учиться писать идеальный код и никогда не научиться, а умение заворачивать и прикручивать свистелки-перделки - позволяет начать продавать свой труд как можно раньше и начать получать деньги.

Prsh

Возможно ли так организовать процесс, чтобы поддержка на уровне исходного кода не требовалась бы никогда, и соответственно никто бы никогда не мог узнать говнокод там внутри или нет. Например, когда мы отдаем автомашину в мастерскую на ремонт, то там у работников не возникает вопрос хорошо ли спроектирован насос: он либо работает либо нет; в последнем случае его меняют на другой. И никто в него не лезет чтобы понять говнонасос это или нет. (Завод-производитель конечно все равно будет вынужден копаться во внутренностях; я тут рассматриваю самого производителя насосов как одно “лицо”. Если программист написал такой код в котором сам не может разобраться, то это уже его внутренние проблемы)

V_Alex
Prsh:

И никто в него не лезет чтобы понять говнонасос это или нет…

Попрошу не впутывать говнонасосы в ваши гнилые программерские разборки 😃 Говнонасосы или фекальные (они-же - канализационные) насосы - это высший уровень насосостроения 😃 и далеко не всякая насосная фирма может позволить себе их выпуск: www.sololift-sololift.ru/grundfos_sololift.php 😃

6wings
Prsh:

Возможно ли так организовать процесс, чтобы поддержка на уровне исходного кода не требовалась бы никогда, и соответственно никто бы никогда не мог узнать говнокод там внутри или нет

только для очень маленьких и компактных программ.

Во всякой большой программе есть как минимум 3 ошибки. Когда их устраняют, обнаруживаются/привносятся следующие 3 и т.д. В дальнейшем этот процесс может продолжаться до бесконечности” - народная мудрость.

На самом деле наибольшие неприятности доставляют не ошибки кодирования алгоритмов - подавляющее большинство их обычно так или иначе выявляются на этапах альфа и бета-тестирования, а отсутствие проверок граничных значений параметров. За счёт существования таких ошибок появляются трудно диагностируемые сбои и, что самое неприятное, осуществляются взломы.

И еще: я не очень хорошо понимаю, что участники дискуссии понимают под словом “говнокод”.
Если программа прошла приемку по структуризации, оформлению, объему памяти, времени выполнения и альфа+бета тестированию, то код является рабочим. Ситуация, когда “сам программист не может разобраться в том, что он написал”, должна исключаться на этапе проверки структуризации и оформления.

Если кто-то считает, что каждая строка написанного кода должна контролироваться “проверяющими”, то на мой взгляд - это абсурд. Бессмысленная растрата человеческого времени и людских ресурсов.
Для того, чтобы исходник был формально принят, он должен быть в таком состоянии, чтобы другой программист соотв. квалификации мог в нем разобраться и, при необходимости, что-то модифицировать. Всё остальное выявляется при тестировании.

Prsh
V_Alex:

Попрошу не впутывать говнонасосы…

Искренне прошу меня извинить… не учел что тут могут быть специалисты по разным приборам…)))

6wings:

И еще: я не очень хорошо понимаю, что участники дискуссии понимают под словом “говнокод”.

Вот-вот. Мне кажется что “неучет граничных условий” это не говнокод. Последнее - это по-моему когда ни любой проверяющий (ни сам программист через неделю) глядя на код не может понять WTF!

6wings

Я думаю, что надо разделять 2 различных ситуации:

  1. когда люди пишут “сами для себя”
  2. когда производится “промышленное” производство программ

В первом случае, неопытные программисты действительно могут производить большие куски запутанного кода, в котором сам черт ногу сломит. Но в случае промышленного производства такая ситуация должна быть автоматически исключена при приемке исходников.

ADF

В моем понимании говнокод - это когда задача решается либо явно не оптимальным способом (банальная сортировка пузырьком при отсутствии ограничений в памяти), не учитывает возможности конкретного языка (грубо говоря, когда школьник в своей программе заводит два десятка однотипных переменных вместо массива 😃), либо когда решение является костылем, да еще и неаккуратным (“если он пасть закроет - у него на ж0пе кожа лопнет” 😃).

6wings
ADF:

заводит два десятка однотипных переменных вместо массива

не понял. Массивы нужны в тех случаях, когда нужна индексация. Если индексация не нужна, то простые переменные работают всегда (!) эффективней.

ADF:

сортировка пузырьком при отсутствии ограничений в памяти

  1. обычно если есть ОС и библиотеки, то самому сортировку писать не требуется
  2. если “пузырёк” не вылезает из временнЫх ограничений - наплевать.
ADF:

если он пасть закроет - у него на ж0пе кожа лопнет

вообще не понял.

На мой взгляд, плохой исходный код - запутанный, необозримый (большой и одним куском), плохо структурированный и плохо самодокументированный.
Еще раз: условия по памяти, скорости и ошибкам алгоритмов - другие этапы проверки.

Наверное, здесь тоже есть смысл ввести 2 градации:

  1. качество самого исходного кода (“понятность” и “понимаемость другими”)
  2. качество реализации алгоритмов (память, скорость, ошибки)

Не надо всё валить в одну кучу.

Prsh
6wings:

Я думаю, что надо разделять 2 различных ситуации: 1) когда люди пишут “сами для себя” 2) когда производится “промышленное” производство программ

Я предполагал именно промышленное окружение. (Если сам для себя пишешь, то что написал то и с’ел - сам себе хозяин и судья; и свое врядли кто назовет меньше чем гениальный код…))).
Мне кажется, что как ни странно, как раз в промышленных продуктах и присутствует много этого самого. Видимо приемщику главное что бы работало (пусть как-то, пусть сейчас…). Еще раз, в моем понимании говнокод -это когда квалифицированный программист смотрит на код и не может понять что это и зачем, как когда мы смотрим на помойку. Если логика ясна, но написано не оптимально, и не все учтено,то такого программиста еще можно спасти.))
П.С. я не профессиональный программист, так что это все мои гнусные домыслы)) ; с др. стороны, много общался с программистами))

6wings:

вообще не понял.

rcopen.com/forum/f6/topic205897/9024
😁

6wings
Prsh:

Видимо приемщику главное что бы работало (пусть как-то, пусть сейчас…).

ну еж-тыть… Приёмка - это СОВСЕМ не один этап!!!

На этапе приёмки ИСХОДНИКОВ ни о каком “работало/не работало” речь еще не идёт. Оценка производится по принципу “кто ясно мыслит - тот ясно излагает”

ADF
6wings:

то простые переменные работают всегда (!) эффективней.

Бывают графические процессоры. Которые заточены под перемножение матриц и т.д. Простые переменные будут ячейками внутри массива и индивидуальная работа с ними будет значительно медленнее, чем валовая обработка данных.
Можно еще много примеров привести, да и опять-же - зачастую массивы применяются не для быстродействия, а для удобоваримости и расширяемости кода.

6wings:

… не вылезает из временнЫх ограничений - наплевать…

Го8нокод - это не тот код, который не работает или глючит. А тот, который нарушает читаемость и\или расширяемость проекта или как либо еще демонстрирует невысокий уровень человека, который его написал.

Вот как-то так вот оно. 😃

6wings
ADF:

Го8нокод - это не тот код, который не работает или глючит. А тот, который нарушает читаемость и\или расширяемость проекта или как либо еще демонстрирует невысокий уровень человека, который его написал.

вот это в самую точку! ))