Нужен совет по оптимизации функции

ДоХтор, думаю это из самого устройства яп, товарищ кстати хорошо в яве разбирается

ДоХтор, в доке речь идет о ЯП, а я говорю об общих правилах и стандартах. Любой вызов, который работает с файловой системой, базой данных, глобальными переменными, сетью и т.д. можно считать глобальным, а внутри одной функции допустим (по хорошему) только один глобальный вызов.

# Delphinum (26.08.2016 / 21:40)
ДоХтор, в доке речь идет о ЯП, а я говорю об общих правилах и стандартах. Любой вызов, который работает с файловой системой, базой данных, глобальными переменными, сетью и т.д. можно считать глобальн

Понятно. Но как тогда добиться одного глобального вызова? Разделять код на несколько пользовательских функций, каждая под один вызов?

ДоХтор, сильно от задачи зависит. По хорошему нужно работать с данными, одна функция предоставляет их, другая обрабатывает, третья записывает.

Delphinum, тот же file_get_contents сохраняет дискриптор в открытом состоянии, так что при работе с одним файлом, как в данном случае

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

Delphinum, одна функция предоставляет их, другая обрабатывает, третья записывает.

То есть, три разных функции, как я и предположил в посту выше? Ок, попробую разделить код на несколько функций.

ДоХтор, три разные функции это как вариант. Я не силен в процедурном программировании, потому не знаю true way для минимизации повторений кода.

# Delphinum (26.08.2016 / 21:49)
ДоХтор, три разные функции это как вариант. Я не силен в процедурном программировании, потому не знаю true way для минимизации повторений кода.

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

ДоХтор, ну это естественно, для того функции и нужны. Проблема только в том, что никто не знает, когда понадобится та или иная функция. Я считаю (перенося опыт из ООП), что у функции должна быть "одна причина для изменений", тобишь менять код функции (или писать ее аналог) нужно будет только по одной причине. К примеру функция получающая и возвращающая данные о кликах имеет только одну причину для правки - смена хранилища (с файла на базу, на пример). Но если одна функция будет и из файла данные тащить, и отображать их и записывать результаты, то причин для ее правки будет более одной, а это не есть хорошо.