Курилка программистов

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[RayTwitty 492]

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

 

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

Изменено 10 Декабря 2015 пользователем RayTwitty

[Serge! 127]

Такое ощущение, что выполнение кода ушло внутрь SLEEP, а про остаток в функции с условиями оно забыло

может и так, а может и потому, что метод level.start_stop_menu для открытия/закрытия должен получать в качестве 1-го параметра адрес одного и того же экземпляра окна. В Вашем же примере явно используется метод не входящий в стандартной пространство имен level (level.start_stop_menu(level.get_inventory_wnd(), true)). Что он делает я не знаю, но если он не возвращает ссылку на открытое ранее окно, то почему же в таком случае оно  должно закрываться? 

Изменено 10 Декабря 2015 пользователем Serge!

[RayTwitty 492]

@Serge!, нет, с точки зрения вызова там все корректно - get_inventory_wnd возвращает объект окна инвентаря. Вопрос в общем-то не об этом был - не важно, закрытие инвентаря или вывод в лог сообщения - вызываться это не будет при условиях, которые я обозначил.

 

А закрыть инвентарь мне удавалось, написав после SLEEP железно вызов (т.е. продублировав его внутрь блока с последним условием):

...
if cond4 then
	SLEEP -- call external func
	level.start_stop_menu(level.get_inventory_wnd(), true)
else
...

Изменено 10 Декабря 2015 пользователем RayTwitty

[ed_rez 16 109]

Ребят, вот вы "потрошите" движок... Вопрос. Есть ли в ТЧ возможность восстановить/создать возможность использования всех возможностей ЗП движка по анимациям?

Понимаю, что не "удобное" по смыслу дело! А все таки кто-то задавался таким вопросом? (понимаю, что вопрос будет без ответа, но все же..., есть же альтруисты, как я...)

Изменено 10 Декабря 2015 пользователем ed_rez

[Serge! 127]

вызываться это не будет при условиях, которые я обозначил.

я прогнал в чистом Lua этот код

 

local cond1, cond2, cond3, cond4 = false, false, true, true
local fun = function()
    if not cond1 then
        if not cond2 then
            if cond3 then
                if cond4 then
                    --SLEEP -- call external func
                    print('cond4 - true')
                else
                    print('cond4 - false')
                    -- show message4 (CUIStatic)
                end
            else
                print('cond3 - false')
                -- show message3 (CUIStatic)
            end
        else
            print('cond2 - true')
            -- show message2 (CUIStatic)
        end
    else
        print('cond1 - true')
        -- show message1 (CUIStatic)
    end
    print('конец')
--	level.start_stop_menu(level.get_inventory_wnd(), true) -- hide inventory window
end

fun()

 

 

всё отработало ожидаемо

--> cond4 - true

--> конец

значит цепочка/лесенка здесь не виновата.

Изменено 10 Декабря 2015 пользователем Serge!

[RayTwitty 492]

@Serge!, возможно чисто сталкеркий косяк. В чистом lua да, всё работает.

[Expropriator 2 118]

@ed_rez, конечно есть такая возможность. Движок ЗП был основан на ТЧ и ЧН. Надо просто перенести свою игру на платформу ЗП.  

ПС: начните работать с ЗП и вы поймёте, что 1602 идеальная база для модинга и интегрирования правок в движок. Используйте визуалку 2008 года.

[Malandrinus 615]

куда делся оператор and?

Ну я не стал расписывать более тяжёлый вариант, из-за которого собственно и делают каждое условие по-отдельности.

function fff()
    if cond1 then
        ... -- долго вычисляем cond2
        local cond2 = ...
        if cond2 then
            ... -- долго вычисляем cond3
            local cond3 = ...
            if cond3 then
                ... -- и т.д.
                if cond4 then
                    if cond5 then
                        --do_something
                    end
                end
            end
        end
    end
end

мы говорим о субъективной вещи. Кому то лесенка вполне читаема.

Разница между вложенными и последовательными if вполне осязаемая. Когда читаешь вложенные if, то для расшифровки всей конструкции надо "отложить в памяти" каждый if в этой конструкции. Это наподобие рекурсивного вызова: каждый вложенный if - очередной уровень рекурсии. При линейном же расположении условий такого нет: закончилось условие - забыл про него, перешёл к следующему. Когда подошёл к самому внутреннему уровню, то ничто уже не засоряет в сознании то действие, которое собственно выполняется.

 

Отвечаю сразу тем, кто скажет что-то вроде: "что, сложно немного лишнего напрячься и подумать?" Да, сложно. Мне хватает реальных сложностей, чтобы не создавать себе сложности искусственные. А это именно сложность. Одно такое место в коде, другое - и вот уже я трачу на его разбор не десять минут, а час.

 

 

Собственно, из-за концепции структурного программирования и делают, как ты говоришь "лесенкой".

Ну так я же и сказал, что множественные return нарушают. Это примерно тоже самое, что выходы с помощью goto из вложенных циклов или тех же if-ов. Кстати, очень жаль, что в версии Lua для сталкира нет goto. В поздних то версиях уже добавили.

 

 

 

Но в обычных условиях, таких простынь вряд ли получится

Ты шутишь что ли?! Да меня уже от этих "лестниц" тошнит, столько я на них насмотрелся.

 

 

 

Вот все ругают оператор goto. Не пойму чем он так плох?

Плох тем, что с его помощью без должного понимания основ структурного программирования и самодисциплины можно сделать совершенно нечитаемый и крайне нестабильный код. Хорош же тем, что при наличии указанных понимания и самодисциплины можно сильно упростить код в ряде случаев. Типичный пример - прервать вложенные циклы. Нет совершенно никакого вреда в том, чтобы сделать выход из самого внутреннего цикла по условию на метку снаружи всех циклов. А без goto для этого придётся извращаться.

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

Изменено 11 Декабря 2015 пользователем Malandrinus

[Serge! 127]

я не стал расписывать более тяжёлый вариант

а если так?

local cond1 = function() cond = true; print('cond1'); return cond end
local cond2 = function() cond = true; print('cond2'); return cond end
local cond3 = function() cond = true; print('cond3'); return cond end
local cond4 = function() cond = true; print('cond4'); return cond end
local cond5 = function() cond = true; print('cond5'); return cond end
local something = function() print('something'); return false end

local tcond = {cond1(), cond2(), cond3(), cond4(), cond5(), something()}
local counter, out = 0
function fff ()
    repeat
        counter = counter  + 1; out = tcond[counter]
        if out then fff() end
    until not out
end

 

 

Изменено 11 Декабря 2015 пользователем Serge!

[RayTwitty 492]

Ты шутишь что ли?! Да меня уже от этих "лестниц" тошнит, столько я на них насмотрелся.

У меня нет таких лестниц Точнее, была только одна - её я и написал тут чуть ранее, но сейчас тот код переделан.

 

Ну я не стал расписывать более тяжёлый вариант, из-за которого собственно и делают каждое условие по-отдельности.

Ну этот код можно точно также написать в одно условие, а вот если добавить else, тогда придется делать лесенку.

[Serge! 127]

а вот если добавить else, тогда придется делать лесенку.

я бы не высказывался так однозначно. Практика показывает, что из почти любого положения есть, по крайней мере два выхода. Иногда их даже три.

Сразу скажу, что и с "else" это решается, в концепции ООП, достаточно элегантно и не слишком сложно без всякой "лесенки". Подумайте сами как.

 

этот код можно точно также написать в одно условие

можно, но даже при этих пяти он будет скорее всего более трудно читаем и воспринимаем, чем эта "лесенка". А если таких условий десяток или несколько? Malandrinus ведь именно о таком развитии событий говорил, а не о каких-то частных решениях.

Дайте нам примерчик такого своего решения "в одно условие", вариантов этак на 23-37, вместо теоретических выкладок. Вот тогда и будет повод для предметного обсуждения.

Мне показалось, что Вы очень любите всё критиковать, но не очень готовы делиться своими находками. Вот пример, чтобы не быть голословным: "была только одна - её я и написал тут чуть ранее, но сейчас тот код переделан". И молчание! Так покажите нам конечный результат (исходник то мы уже видели) и мы будем учиться, как побеждать такие проблемы. Я, лично,  всегда с большим удовольствием и с огромным вниманием отношусь к чьим-то программным разработкам и находкам.

 

Изменено 11 Декабря 2015 пользователем Serge!

[RayTwitty 492]

Мне показалось, что Вы очень любите всё критиковать, но не очень готовы делиться своими находками

От того, что я переделал код изначальный вопрос не снялся - старый код не работал (не было вызова), хотя должен был быть.

Но если интересно, вот так выглядит новый код:

 

local message = ""
if cond1 then
	message = "text1"
elseif cond2 then
	message = "text2"
elseif cond3 then
	message = "text3"
elseif cond4 then
	message = "text4"
elseif cond5 then
	message = "text5"
end
level.start_stop_menu(level.get_inventory_wnd(), true) -- hide inventory window
if message ~= "" then
	-- show message (CUIStatic)
else
	SLEEP -- call external func
end

 

А если таких условий десяток или несколько? Malandrinus ведь именно о таком развитии событий говорил, а не о каких-то частных решениях.

Больше 4-5 у меня никогда не было в одном условии. Впрочем, использование лесенок и return'ов уже обсудили - зависит от случая. У меня есть места, где я и то, и другое применяю в одной функции. Хотя не совсем удачный пример (по-хорошему надо было ещё визуал проверить, да и мало условий), но тем не менее... Изменено 11 Декабря 2015 пользователем RayTwitty

[Serge! 127]

вот так выглядит новый код:

но это принципиально новый алгоритм, в котором Вы к тому же поменяли одну лесенку на лесенку другого вида. В старом примере при не соблюдении первого условия вся цепочка прерывалась, а в новом осуществляется последовательная проверка всех возможных условий. Это суть разные вещи. Но и это не главное. Вот почему такое, как Вы говорите,  работает? тоже мне не очень понятно (почему старый не работал я Вам намекнул). Видимо потому, что это только фрагмент кода и что-то осталось за кадром.

Повторюсь: метод level.start_stop_menu работает (с одним и тем же окном) на показать/скрыть только в паре (как тригер) при вызове в одном модуле или явной передачи ссылки на него в другой. По крайнем мере у меня только так всегда и получалось.

 

 

где я и то, и другое применяю в одной функции

это тоже было бы интересно посмотреть (4-5 в одном условии). Просто, как такое может выглядеть? Когда я такое пытался сделать, то это смотрелось ужасно.

Изменено 11 Декабря 2015 пользователем Serge!

[RayTwitty 492]

ничего принципиально нового в нём я не увидел

А я и не говорил, что в нем будет что-то принципиально новое. Вопросили - получили.

 

почему старый не работал я Вам намекнул

И почему же? Еще раз повторяю, от вызова конкретных функций результат не зависит, проблема видимо именно в lua сталкера.

 

это тоже было бы интересно посмотреть (4-5 в одном условии). Просто, как такое может выглядеть?

if a > b and c == b and d ~= a and call_func() then

Хотя нет, даже такого у меня не было.

[Serge! 127]

 

 

Хотя нет, даже такого у меня не было

ну и славненько, т.к. я совершенно не такое имел ввиду, когда спрашивал про "одно  условие". Я думал, что Вы говорите о "сворачивании" лесенки  в пяток ступенек в последовательность "and ... or...". 

Просто на заметку: в Lua такие конструкции, из-за его чрезмерной внутренней оптимизации, иногда ведут себя совсем не так, как ожидается.

 

 

проблема видимо именно в lua сталкера.

вряд ли. Это всё настолько примитивно, с точки зрения синтаксиса, что списывать на огрехи системного экспорта не стоит.

[RayTwitty 492]

 

 

Это всё настолько примитивно, с точки зрения синтаксиса, что списывать на огрехи системного экспорта не стоит.

Тут видимо дело не в синтаксисе, а в том, как интерпретатор обрабатывает код. Впрочем, все уже сказано, хотелось бы услышать мнение экспертов конкретно по lua.

[Nazgool 250]

Предлагаю для обсуждения простую мысль

...

С алгоритмической точки зрения здесь всё нормально, однако подобное крайне плохо воспринимается.

Да нормально воспринимается и первый и второй вариант.

Тут смотря кто как воспринимает.

Думаю что если Lua позволяет такую "вольность" в синтаксисе, то каждый и выбирает для себя наиболее приемлемый вариант.

Когда читаешь вложенные if, то для расшифровки всей конструкции надо "отложить в памяти" каждый if в этой конструкции

 

Скорость Lua достаточно высока чтобы не обращать внимания на создание в стеке таких локальных переменных.

А если учитывать что в Сталкере компилируется в luajit, то и подавно.

И в конце концов Lua это высокоуровневый язык, и следить из lua скриптов что там делается на уровне стека и дальше - это "ниже его достоиства"

Если кто-то слишком заботиться о скорости, то пусть пишет код на С.

А кто умеет писать быстро на Lua, тот напишет как нужно.

 

Тут скорее всего всё упирается в квалификацию скриптера.

Если скриптер образованный, то ему по силам прочитать любой вариант кода.

Ну а если нет, то ... как там Ленин говорил? Учиться?

Изменено 12 Декабря 2015 пользователем Nazgool

[Desertir 202]

@Nazgool, о скорости выполнения не было ни слова. Речь идет о скорости восприятия кода только человеком.

Тут смотря кто как воспринимает.

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

ему по силам прочитать любой вариант кода

Опять же, не в этом дело, а в том, на сколько это удобно прочитать, а соответственно и быстрее понять. Рассматривается не случай "я не могу понять этот код", а "я медленно воспринимаю многовложенные блоки кода".

Да, сложно. Мне хватает реальных сложностей, чтобы не создавать себе сложности искусственные. А это именно сложность. Одно такое место в коде, другое - и вот уже я трачу на его разбор не десять минут, а час.

---------------------------------------------

Я только хочу сказать, что это воспринимается по-разному у различных программистов, кому то удобно, кому то не очень. Я отношусь больше к последним.

[Dennis_Chikin 3 658]

"Эргономика - лженаука !"

 

Хотя вот вообще-то в свое время было много чего изучено и написано про восприятие в зависимости от геометрии и содержимого этого самого воспринимаемого.

Цвет, кстати, в общем-то туда же.

 

У Ефремова, кстати, просто потрясающе описано "как делать НЕ надо, и к чему это приводит".

 

Да, есть некоторый разброс, да, когда проводились исследования, слыхом не слыхивали о ЖК мониторах, но основные принципы в целом работают. И то, что большинство из этого идет в разрез с идеями современных "креативных" маркетоидов - оных маркетоидов отнюдь не красит.

[Malandrinus 615]

Ну этот код можно точно также написать в одно условие

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

 

а если так?

Мне кажется, что так ещё более мудрёно. И опять же применимо то, что я выше написал. Часто, если не всегда, вычисление очередного условия в "матрёшке" подразумевает выполнение предыдущего условия (и также использует данные, полученные на этапе вычисления предыдущих условий). В твоём же варианте все условия изолированы.

 

Скорость Lua достаточно высока чтобы не обращать внимания на создание в стеке таких локальных переменных.

=) Я не имел в виду скорость трансляции при выполнении. Я говорил о скорости разбора кода человеком. Человек - очень медленное устройство, поэтому всё развитие технологий разработки ПО связано с повышением эффективности именно человека, как слабого звена в цепочке. Обратите внимание, что весь прогресс в программировании непременно связан с фактическим снижением скорости работы программ. Зато программисту работать всё легче и легче.

 

Если скриптер образованный, то ему по силам прочитать любой вариант кода.

Тебе нравится тратить время зря? Когда-то и я по молодости считал, что трюкачество в коде - это круто, но это было давно.