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

[RayTwitty 491]

Это конечно отступление от Истинно Структурного Программирования, но на это как-то и начхать.

Собственно, из-за концепции структурного программирования и делают, как ты говоришь "лесенкой". Но в обычных условиях, таких простынь вряд ли получится - лично я привык некоторые повторяющиеся действия (а они чаще всего повторяются (вызываются) где-то ещё), оборачивать в отдельные функции, вроде "return a and b and c". Впрочем, само использование return, break, continue и т.д. уже не есть структуры, так что на эти формальности можно забить. Где-то удобнее сделать выход в начале функции, где-то построить лесенку, зависит от случая.

 

Кое-где я у себя даже goto юзаю 

 

А можно узнать сакральный смысл двойного arg? Почему не local t = arg or {...} ?

arg and arg or {...}

эквивалент

arg ? arg : {...}

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

[RayTwitty 491]

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

 

function()
	if not cond1 then
		if not cond2 then
			if cond3 then
				if cond4 then
					SLEEP -- call external func
				else
					-- show message4 (CUIStatic)
				end
			else
				-- show message3 (CUIStatic)
			end
		else
			-- show message2 (CUIStatic)
		end
	else
		-- show message1 (CUIStatic)
	end
	level.start_stop_menu(level.get_inventory_wnd(), true) -- hide inventory window
end

 

И вот интересность этого кода в том, что при отработке SLEEP (прохождения всех условий), закрытия инвентаря не происходило (туда просто не доходил вызов). Отчего так могло быть? Такое ощущение, что выполнение кода ушло внутрь SLEEP, а про остаток в функции с условиями оно забыло

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

[RayTwitty 491]

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

 

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

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

[RayTwitty 491]

@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

[RayTwitty 491]

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

[RayTwitty 491]

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

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

 

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

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

[RayTwitty 491]

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

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

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

 

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

[RayTwitty 491]

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

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

 

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

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

 

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

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

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

[RayTwitty 491]

 

 

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

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

[RayTwitty 491]

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

Ты имеешь ввиду лишние вызовы?

for i = 1, 65535 do
if alife():object(i) and level.object_by_id(i) and level.object_by_id(i):is_stalker() then ... end
end

смущает что два раза вызвал object_by_id?

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

[RayTwitty 491]

У тебя в цикле перебора всего диапазона id три раза вызываются функции, которые сами по себе перебирают все объекты

Впрочем, речь то не об этом.

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

 

Я же ранее явно в примере кода указывал "долго вычисляется условие такое то"

Обычно, я "долгие вычисления" делаю где-то в другом месте, а не внутри общей функции. Впрочем, тут дело вкуса - кто-то любит в одну функцию напихать, а кто-то разбивает на подзадачи (доп. функции) и вызывает когда ему нужно. Да и нагляднее это получается - зачем мне видеть процесс, например сортировки массива, если в данной задаче интересно увидеть только результат. Изменено 14 Декабря 2015 пользователем RayTwitty

[RayTwitty 491]

Совершенно типичная ситуация, что ты не можешь вычислить условие 2 до тех пор, пока не выполнено условие 1, а условие 3 до тех пор, пока не выполнено условие 2 и т.д. Неужели это настолько непонятно?

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

a & b & c

Если a = 0, то дальше даже смотреть не будет, соответственно там может быть все что угодно.

 

З.Ы. впрочем, есть ли конкретный код, в скриптах ОГСЕ например? Они у меня в наличии.

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

[RayTwitty 491]

@Malandrinus, во-первых, я буду поминать те вещи, которые считаю нужным; во-вторых, не надо иметь семи пядей во лбу чтобы знать 0 & .. & .. = 0, поэтому твои линки тут неуместны.

 

 

 

В этом аппарате нет никаких указаний насчёт обязательности/необходимости вычисления входящих в выражение условий.

В тех языках, которые я подразумевал (и которые скорее всего подразумевали другие), это свойство прекрасно работает.

 

Функция может получиться сугубо одноразовая (что само по себе лишает её смысла)

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

 

А тут кстати упоминали ещё и вариант с веткой else.

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

 

Если вернуться к изначальному вопросу:

 

Есть ли какие-то мысли по этому поводу?

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

 

Думаю, я ответил на вопрос.

 

З.Ы. забыл написать - наверняка воспринимаемость также зависит от монитора - лесенку удобно рассматривать на 21:9))

Изменено 15 Декабря 2015 пользователем Black Hawk
Объединение постов.

[RayTwitty 491]

Просто несколько забавно видеть упоминание мат.логики для красного словца.

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

 

Ты полностью проигнорировал сказанное

Я уже давно попросил привести какой-нибудь пример из реального кода, в тех же скриптах.

 

А что касается "реализации аппарата логики" - там где я работаю, он полностью соответствует моему пониманию:

local a = false
if a and print("first") then
end
print("two")

 

Завести функцию "про запас", только чтобы выделить несколько строк?

Не только - я там написал ещё для чего.

 

Береги глаза смолоду

Это зависит не от соотношения сторон монитора, а от многих других параметров) Изменено 15 Декабря 2015 пользователем RayTwitty

[RayTwitty 491]

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