Как вы считаете, что будет с программированием в недалеком-далеком будущем?
… от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”.
На самом деле - это соответствие уровня кода - решаемой задаче. Но ни в коем случае не надо путать это - с идеальностью кода как самобытной (мифической и недостижимой) сущностью 😃
…можно специально сделать обычный код практически нечитаемым, например, в целях защиты…
Это называется обфускация, если вы вдруг не знали 😃
Как и многие другие методы “защиты”, помогает лишь условно. От китайских ре-инженеров ничего не спасает 😃
На самом деле - это соответствие уровня кода - решаемой задаче.
ничего подобного. Вы опять не поняли.
Мы на разных языках что ли говорим?
Человек может очень грамотно рассуждать и хорошо понимать, что он делает. Но при этом может банально изобретать велосипед - что в программировании распространено сплошь и рядом. Причем велосипед - не современный спортивный, а очень качественный, но трехколесный и детский 😃 Образно говоря.
Это распространено повсеместно, а уж в обособленных коллективах, да если вдруг они не сами на рынок свои проекты выводят, а принимают задания от заказчика - это аж мхом порастает, но никто этого не замечает.
Это называется обфускация, если вы вдруг не знали
ну почему ж не знал? Сам делал обфускаторы, которыми даже другие пользовались ))
В частности, для незабвенной платформы 1С был у меня обфускатор под названием “Кирпичный заводик”. Ставший, кстати, потом очень популярным в народе ))
Код такими кирпичами укладывал - хрен прочитаешь.
не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))
“перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.
Описание можно написать любое и тестирование выявит только результат работы, а не сам код.
вспомнилось: в литературе почти не описывается один редко встречающийся (в силу своей сложности), но изощренный вид обфускации. Он применим только к процессорам, имеющим команды переменной (разной) длины. Суть его в том, что переход может осуществляться не на начало команды, а на её середину, что, в свою очередь приводит к выполнению совершенно другой команды, код которой является операндом “правильной” команды. В эпоху ЕС ЭВМ мы иногда баловались этим, тем более, что мой собственный дисассемблер раскладывал код на три параллельных цепочки именно с учетом такой возможности.
Технология выглядела так:
-
на ассемблере писался обычный кусок кода, который стандартным образом собирался в объектный код
-
по объектному коду проходились 3-х цепочечным дисассемблером и отыскивали в нем вторичные и третичные более или менее осмысленные куски
-
исходный код слегка модифицировался так, чтобы эти куски реально что-то делали и имели выход (передачу управления) в обычный “первичный” код
На неподготовленные умы результат всегда производил очень сильное впечатление ))
Описание можно написать любое и тестирование выявит только результат работы, а не сам код.
-
речь идет не об “описании”, а о самодокументировании кода. Это совсем другое. (Хотя, общее описание, конечно, тоже нужно)
-
“выявлять” обычно ничего не требуется. Всё видно при беглом просмотре. В свое время существовал даже хороший принцип: “код любой функции не должен занимать больше одной страницы”. Не всегда удаётся ему буквально следовать, но стремится к этому полезно.
-
для проверки работы кода существует альфа и бета-тестирование. Если его результаты удовлетворительны при условии, что исходники оформлены в соответствии с требованиями и не вызывают вопросов - код принимается. При этом, не так важно, предпочитает программист использовать конструкции “for” или “while” - это его личное дело. Но, например, большое количество “goto” сразу вызывает сомнения ))
использовать конструкции “for” или “while” - это его личное дело.
Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать 😃
…большое количество “goto” сразу вызывает сомнения ))
Одно единственное “goto” - вызывает сомнения 😃
Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать
не принципиально, т.к. оптимизировать всё равно будет компайлер ))
Одно единственное “goto” - вызывает сомнения
да, я тоже не люблю ))
Но допускаю. Классический пример - из глубоко вложенного цикла надо резко вывалиться наружу.
Загнать цикл - в функцию, вываливаться через return 😃
Теоретически - да, но практически:
вызов функции - лишние операции с передачей параметров и со стеком. Причем, во внешнем цикле (!) (может, даже и не в одном, а в нескольких вложенных)
И вот тут-то оптимизатор компилятора как раз и не распознает такую эээ … дурь )) Обычно вызовы функций они не имеют права оптимизировать в линейный код.
Не всё так просто ))
Загнать цикл - в функцию, вываливаться через return
тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”. Тогда действительно можно вывалиться через return. Но можно и огрести проблемы с параметрами, если их много. Однозначного решения нет и goto остаётся допустимым.
К тому же, вывалиться совсем наружу - это частный случай. Может понадобиться вывалиться в один из внешних вложенных. Об этом я и написал до того, как заметил опечатку.
Классический пример - из глубоко вложенного цикла надо резко вывалиться наружу.
Андрей, я вот из цикла про баранов вывалился.😃
Или вывалили…
Андрей, я вот из цикла про баранов вывалился
да, с баранами и дворниками (на лобовом стекле?) там было мощно задвинуто…
Еще б немного - и в бесконечный цикл впало )))
мощно задвинуто…
тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”.
Да, имелось ввиду это самое. 😃
Тогда действительно можно вывалиться через 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!