Как вы считаете, что будет с программированием в недалеком-далеком будущем?
в современном мире - за то, что программисты вечно норовят максимально обобщить задачу и от частностей перейти к решению общностей с наприсаниями фрэймворков, движков и собственных скриптов - их нещадно бьют и гонят с работы
“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.
Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.
Вы решили меня поучить как надо работать?
Нет, ни в коем случае!
Однако, коллективов, контор и областей программирования - сейчас невообразимо много. Сейчас многие задачи требуют значительно более быстрого решения, чем, к примеру, даже 10 лет назад. При этом не надо забывать, что конечный пользователь никогда не увидит код программы изнутри, лишь бы не глючило и не тормозило.
Безусловно, это не повод писать - через задницу, но надо ощущать четкую (зыбкую 😃) границу между быстротой разработки (которая важна) и “правильностью” кода (которую никто, кроме тебя, не оценит).
Так имейте в виду, что мне плевать на “говнокод”, …Я сам лично говнокод никогда не писал и другим не…
Сейчас достоверно известно, что с точки зрения совершенства кода (грамотности структурирования проекта, оптимальности реализации функций) - предела совершенства нету. Реально нету. И если столкнуть лбами двух случайных программистов, то у одного из них - код будет го8нокодом по сравнению с кодом другого, и у обоих - код будет жалким подобием кода, написанного неким третьим программистом и т.д. Но при этом все эти программисты - способны решать поставленную задачу и делать это в срок, и З\П могут получать одинаковую, никак не зависящую от красивости их кода.
PS:
Вот интересное видео по теме. Человек в конкретных практических примерах рассказывает, в том числе о важности качества кода. Просто в качестве пояснения моей позиции.
“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.
МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять? У CIO на это в сутках есть максимум 30%, а у них 100%. И их на порядок больше.
Итог - задача нерешаема.
МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять?
-
не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))
-
“перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.
Вдогонку. Ни в коем случае никого не хочу обидеть, но в среде программистов - не принято хвастаться в духе “как красиво я пишу код” 😒
Потому, что каким бы крутым и опытным вы себя не считали, всегда найдутся еще более опытные и крутые кодеры; а даже в самом причесанном коде, но в крупном проекте - легко находятся “черезжопные” конструкции, за которые можно покраснеть как рак, если это увидит кто-то другой…
Гораздо правильнее - принять как данность, что вы (не зависимо от опыта и заслуг) - не самый крутой программист (пока общественность не потребует вас предъявить свой крутой код 😈). И сконцентрировать внимание на работе, на достижениях конкретных поставленных целей 😃
если столкнуть лбами двух случайных программистов, то у одного из них - код будет го8нокодом по сравнению с кодом другого, и у обоих - код будет жалким подобием кода, написанного неким третьим программистом и т.д
Саша, не будем заниматься бесполезным теоретизированием на пустом месте. Я лично знаю как отличить хороший код от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”. Но я также знаю, как можно специально сделать обычный код практически нечитаемым, например, в целях защиты.
Так что, не надо огород городить в пустоте ))
… от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”.
На самом деле - это соответствие уровня кода - решаемой задаче. Но ни в коем случае не надо путать это - с идеальностью кода как самобытной (мифической и недостижимой) сущностью 😃
…можно специально сделать обычный код практически нечитаемым, например, в целях защиты…
Это называется обфускация, если вы вдруг не знали 😃
Как и многие другие методы “защиты”, помогает лишь условно. От китайских ре-инженеров ничего не спасает 😃
На самом деле - это соответствие уровня кода - решаемой задаче.
ничего подобного. Вы опять не поняли.
Мы на разных языках что ли говорим?
Человек может очень грамотно рассуждать и хорошо понимать, что он делает. Но при этом может банально изобретать велосипед - что в программировании распространено сплошь и рядом. Причем велосипед - не современный спортивный, а очень качественный, но трехколесный и детский 😃 Образно говоря.
Это распространено повсеместно, а уж в обособленных коллективах, да если вдруг они не сами на рынок свои проекты выводят, а принимают задания от заказчика - это аж мхом порастает, но никто этого не замечает.
Это называется обфускация, если вы вдруг не знали
ну почему ж не знал? Сам делал обфускаторы, которыми даже другие пользовались ))
В частности, для незабвенной платформы 1С был у меня обфускатор под названием “Кирпичный заводик”. Ставший, кстати, потом очень популярным в народе ))
Код такими кирпичами укладывал - хрен прочитаешь.
не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))
“перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.
Описание можно написать любое и тестирование выявит только результат работы, а не сам код.
вспомнилось: в литературе почти не описывается один редко встречающийся (в силу своей сложности), но изощренный вид обфускации. Он применим только к процессорам, имеющим команды переменной (разной) длины. Суть его в том, что переход может осуществляться не на начало команды, а на её середину, что, в свою очередь приводит к выполнению совершенно другой команды, код которой является операндом “правильной” команды. В эпоху ЕС ЭВМ мы иногда баловались этим, тем более, что мой собственный дисассемблер раскладывал код на три параллельных цепочки именно с учетом такой возможности.
Технология выглядела так:
-
на ассемблере писался обычный кусок кода, который стандартным образом собирался в объектный код
-
по объектному коду проходились 3-х цепочечным дисассемблером и отыскивали в нем вторичные и третичные более или менее осмысленные куски
-
исходный код слегка модифицировался так, чтобы эти куски реально что-то делали и имели выход (передачу управления) в обычный “первичный” код
На неподготовленные умы результат всегда производил очень сильное впечатление ))
Описание можно написать любое и тестирование выявит только результат работы, а не сам код.
-
речь идет не об “описании”, а о самодокументировании кода. Это совсем другое. (Хотя, общее описание, конечно, тоже нужно)
-
“выявлять” обычно ничего не требуется. Всё видно при беглом просмотре. В свое время существовал даже хороший принцип: “код любой функции не должен занимать больше одной страницы”. Не всегда удаётся ему буквально следовать, но стремится к этому полезно.
-
для проверки работы кода существует альфа и бета-тестирование. Если его результаты удовлетворительны при условии, что исходники оформлены в соответствии с требованиями и не вызывают вопросов - код принимается. При этом, не так важно, предпочитает программист использовать конструкции “for” или “while” - это его личное дело. Но, например, большое количество “goto” сразу вызывает сомнения ))
использовать конструкции “for” или “while” - это его личное дело.
Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать 😃
…большое количество “goto” сразу вызывает сомнения ))
Одно единственное “goto” - вызывает сомнения 😃
Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать
не принципиально, т.к. оптимизировать всё равно будет компайлер ))
Одно единственное “goto” - вызывает сомнения
да, я тоже не люблю ))
Но допускаю. Классический пример - из глубоко вложенного цикла надо резко вывалиться наружу.
Загнать цикл - в функцию, вываливаться через return 😃
Теоретически - да, но практически:
вызов функции - лишние операции с передачей параметров и со стеком. Причем, во внешнем цикле (!) (может, даже и не в одном, а в нескольких вложенных)
И вот тут-то оптимизатор компилятора как раз и не распознает такую эээ … дурь )) Обычно вызовы функций они не имеют права оптимизировать в линейный код.
Не всё так просто ))
Загнать цикл - в функцию, вываливаться через return
тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”. Тогда действительно можно вывалиться через return. Но можно и огрести проблемы с параметрами, если их много. Однозначного решения нет и goto остаётся допустимым.
К тому же, вывалиться совсем наружу - это частный случай. Может понадобиться вывалиться в один из внешних вложенных. Об этом я и написал до того, как заметил опечатку.
Классический пример - из глубоко вложенного цикла надо резко вывалиться наружу.
Андрей, я вот из цикла про баранов вывалился.😃
Или вывалили…
Андрей, я вот из цикла про баранов вывалился
да, с баранами и дворниками (на лобовом стекле?) там было мощно задвинуто…
Еще б немного - и в бесконечный цикл впало )))
мощно задвинуто…
тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”.
Да, имелось ввиду это самое. 😃
Тогда действительно можно вывалиться через return. Но можно и огрести проблемы с параметрами, если их много. Однозначного решения нет и goto остаётся допустимым.
На самом деле тут ситуация несколько тоньше и глубже: если внезапно получается аномальное нагромождение вложенных циклов (аналогично - с большим нагромождением вложенных условий) - то примерно в ~70% случаев стоит задуматься о целесообразности реализуемого таким способом алгоритма. Чтобы в итоге раскидать эту кучу на несколько последовательных или даже вовсе не связанных блоков.
И это бывает в самых разных конкретных задачах.
если внезапно получается аномальное нагромождение вложенных циклов
да не надо “аномально”…
Достаточно иметь всего 4 вложенных цикла и выход из самого внутреннего внутрь внешнего. Потребуются либо if c дополнительной переменной и break, либо goto. Самый тривиальный пример.