ТОЛЬКО ОДНО случайное значение из масива:

$input[mt_rand(0, sizeOf($input) - 1)] ?

А мне так нравится)))

я все понимаю, но разве язык указывать не модно? shaelf - ты расслабился и не следишь? :)

О как, ну может быть... Хотя если у тебя это не в цикле который крутится 100000 раз, то мне кажется это не то место, где можно переживать за скорость)))
ИМХО в первую очередь понятность кода (не кого обидеть не хочу), а потом скорость... Как грится "преждевременная оптимизация - корень всех зол".
2squirL Модно, просто по синтаксису видно, что это такое)) А вот за не выделение кода - незачёт))

2SUMDEX Мдя... Слово "кажется" должно присутствовать у суеверных людей, а не у программистов. Что значит кажеться? Проверь!!!!! Или людей нарягать отвечать (чтобы они своё время тратили) это нормально, а самому потрудится? Впредь не нужно слов типа "кажется". Если для тебя этот алгоритм медленый - обосную. Без основания - флуд.

Таак, что у нам изначально?


А хочется чтоб не было временных переменных.
Так в чем проблема?
Пишем:

и зачет.

А если не хочется дополнительных конструкций использовать,
то пиши свои функции.

ИМХО - зачет.

Други,
всем спасибо

shaelf - обещаю исправиться :)

Можно придумать что-нибудь еще более медленное ;)

Не пойму, чем не нравится выбирание методом:

Мне лично написанием))) Для меня изначально это визуальное представление кода, а уж потом оптимизация. Если даже код менее шустрый, но хорошо и понятно оформлен, при этом он проходит по ТЗ, то ИМХО его таким и нужно оставить, чтобы потом, при добавлении/исправлении было проще ошибки искать... Для любителей в экономить приведу реальный кусок кода

И вот такими вот участками код усеян...
Повторюсь ещё раз "преждевременная оптимизация - корень всех зол".
Если можно код сделать более читаемым, то сделайте его таким, невзирая на производительность и уж тем более "мне кажеться". Если код рабочий, но нехватает скорости, включаем профайлер и вперёд, ищем узкие места, переписываем код (ессно изначально создаём пакет тестов). Лично для себя других путей я не вижу (наверное просто не хочу видеть)))).
PS Может у меня мало опыта, но мне читать строчки подобные этой

Довольно пока сложно, поэтому я всё раскладываю на значения и стараюсь любое возвращаемое значение делать примерно так

Т.е. заносить его сначало в переменную, а потом только возвращать. Я осознаю, что каждая переменная увеличивает размер памяти, но повторюсь, пока по тестам я не пойму, что программе нужно работать быстрее, оптимизировать я её не буду))))

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

Эхх, разошёлся я что-то, всё напряжная неделя виновата)
2Dolonet Спасибо за как всегда конструктивные и проффесиональные ответы)))
2Автору. Я надеюсь, что из этого спора ты вынес что-то полезное.
PS Спонсор спора книга "Совершенный код" )))

2shaelf. Ты более прав в данной ситуации, чем я. Тем более, что у меня был на той неделе отпуск, а значит я отдохнувший и полон сил, чего не скажешь о тебе. :)

Я сам пишу код всегда сначала ТОЛЬКО комментариями, причем с иерархией и подробно. Потом уже пишу функции, вернее, их структуру. А наполнить функцию - это уже плевое дело. Вот таким должно быть программирование, а не все-в-одну-строчку. )

Я почти так же))) Только ещё использую псевдокод... Ещё более точно:
UML
скелет
псевдокод
код
очищение от лишних комментов
рефакторинг (если нужно)
проверка на скорость
оптимизация (если нужно)
Если что-то сложное, то использую опережающие тесты.)