Работает у нас в конторе чел (недавно пришел) — 1сник.
Седня спросил у другого 1сника:
""
Ответь мне, пожалуйста, на риторический вопрос. (!!!)
Почему 1сники так любят передавать параметры в процедуры? Вообще зачем передавать в процедуру параметры? Ведь проще сделать глобальные переменные...
""

Люди ударились в небольшую панику.

Здравствуйте, okurietz, Вы писали:

O>Работает у нас в конторе чел (недавно пришел) — 1сник.
O>Седня спросил у другого 1сника:
O>""
O>Ответь мне, пожалуйста, на риторический вопрос. (!!!)
O>Почему 1сники так любят передавать параметры в процедуры? Вообще зачем передавать в процедуру параметры? Ведь проще сделать глобальные переменные...
O>""

O>Люди ударились в небольшую панику.

А мне вот хочется поубивать в последнее время любителей глобальных и статических переменных.....

Ибо на той платформе с которой я работаю нету статических неконстантных данных....


А вообще корректный ответ на это — ибо у каждого объекта (а переменная это объект) должен быть владелец и распоряжаться ею может только он.

Y>А мне вот хочется поубивать в последнее время любителей глобальных и статических переменных.....
Y>Ибо на той платформе с которой я работаю нету статических неконстантных данных....

Из зависити получается?

Здравствуйте, okurietz, Вы писали:

O>Почему 1сники так любят передавать параметры в процедуры? Вообще зачем передавать в процедуру параметры? Ведь проще сделать глобальные переменные...

А ты почитай глобальный модуль...
А потом попробуй запомнить, что туда добавил (не надо о сравнении конфигов — запомни, что ТЫ добавил и что заюзал из того, что в следующем релизе исчезло) и попробуй накатывать апдейты каждый месяц.....

Да и вообще... Кто с 1С работал, тот в цирке не смеется.

Здравствуйте, Young, Вы писали:

Y>А вообще корректный ответ на это — ибо у каждого объекта (а переменная это объект) должен быть владелец и распоряжаться ею может только он.

Не "должен быть", а "было бы удобнее, если бы был". Скрытие данных вещь сама по себе искусственная и несет только удобство программисту и замедление времени работы. У глобальных переменных один минус — они постоянно живут в памяти.

Здравствуйте, Infix, Вы писали:

I>Не "должен быть", а "было бы удобнее, если бы был". Скрытие данных вещь сама по себе искусственная и несет только удобство программисту и замедление времени работы. У глобальных переменных один минус — они постоянно живут в памяти.

Это был ты, да?

Здравствуйте, Дарней, Вы писали:

Д>Это был ты, да?

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

Здравствуйте, Infix, Вы писали:

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

Про структурное программирование не забыли, да?
Каждая процедура имеет некоторый контекст выполнения. В принципе, достаточно такого объявления на все случаи жизни:

struct Context;
struct Args;
struct Result;
void routine(/*in,out*/ Context& context, /*in*/ const Args& args, /*out*/ Result& result);

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

Если мы немного с другой стороны взглянем, то получим...

class Args;
class Result;

// требуется полное объявление хотя бы типа Result

class Context
{
public:
  Result routine(const Args& args);
  ...
};

Знакомо, не правда ли?