• C тем, что количество глобальных переменных должно быть сведено к минимуму, знакомы многие. Но многие не понимают, почему это так. На самом деле, подобное ограничение связано с тем, что глобальные переменные могут меняться непредсказуемо - вызываемыми процедурами, например, или даже другими потоками. Именно поэтому цикл For не допускает для использования в качестве счетчика итераций глобальные переменные - потому что это грозит случайным изменением порядка выполнения работы и нарушением работы цикла. К примеру, возьмем знаменитый DecimalSeparator. Бог с ним, при использовании стандартных функций VCL ничего страшного не наблюдается. Но возьмем, например, некую процедуру MySuperProc из библиотеки стороннего разработчика. Пусть даже у нас будут исходные коды этой библиотеки - но при использовании процедуры мы считаем ее черным ящиком. Пусть до и после вызова мы выполняем действия, связаные с преобразованием чисел в строки и обратно. Мы НЕ МОЖЕМ гарантровать, что наш "черный ящик" оставил DecimalSeparator в том состоянии, в котором он был до вызова, хотя подсознательно пишем код, как если бы это было так. Неимоверная сложность отслеживания взаимодействий ДОЛЖНА ограничивать число глобальных переменных жизненно необходимым минимумом. Это не относится к глобальным функциям, вроде Printer, который часто путают с глобальной переменной. Эта не переменная - она не меняется, а возвращает значение "внутренней" переменной. Именно по этой причине рекомендуется использование свойств (property) в объектах (классах), а не полей. При изменении свойства мы можем оповестить все заинтересованные структуры через сеттер и сознательно РАСЧИТЫВАЕМ на возможность изменения. Если возможность изменения полей внутри выполнения процедуры недопустима, то необходимо создать их локальные копии, или деактивировать сеттер. Я для локальных копий использую префикс l, также как для private полей - префикс f, а для передаваемых в процедуры типа конструктора инициализирующих параметров - префикс a. Посмотрите функции, которые используют TFormatSettings. Пример приведен в »вопрос КС №33804«
  Вред глобальных настроек могу продемонстрировать еще одним примером. Вот сейчас ушел на полчаса от компьютера, а когда вернулся - экран горит. Лезу в настройки электропитания, а там - правильно, стоит тема "Intervideo...". И это с учетом того, что проигрыватель я удалил несколько месяцев назад, а тему электропитания приходится менять каждую неделю. На вирус подозрений нет - Касперский от июня с.г. молчит как рыба, но неприятный осадок регулярно все-равно остается. Вот бы настроить все личные настройки и сказать: "А теперь пока я ЛИЧНО не разрешу - никому не трогать настройки". Но такого, увы, нету.
  
• >>> Не бросаться с места в карьер
  Точно. Не поддаваться настронию, что "я это за пять минут сделаю". Потом будете год расхлебывать то, что второпях наразрабатывали. Помните - каждый час, вложенный в проектирование, обернется несколькими днями экономии на этапе разработки. Экономить на разработке - себе во вред.
  
• >>> Допустим нужно из главной формы вызвать модальную
  Для этого все просто - создаем функцию, которая бы редактировала значение переданного параметра. Например, типа string. Возвращаемый результат - типа boolean, как раз - произошло ли изменение. Ваш пример будет работать гораздо разумнее при оформлении:
  

  function GetSomeData(var S:string):boolean;
  begin
    Result:=false; // in case of failure
    with TSomeEditForm.Create(nil) do try
      Edit1.Text:=S; // вносим данные в поля формы
      Result:=ShowModal=mrOk; // редактируем.
        // При нажатии на Ok ДОЛЖНА проходить полная верификация данных.
        // Только если она прошла, ModalResult может принять значение mrOk.
        // Отмена должна проходить без дополнительных проверок.
      if Result then begin
        S:=Edit1.Text; // возвращаем в параметре значение
      end; 
    finally
      Free;
    end;
  end;

  
  Вызов будет очень простым и понятным:
  

  procedure Button1Click(Sender:TObject);
  var S:string;
  begin
    S:=Table1.FieldByName('Family').AsString;
    if GetSomeData(S) then begin
      Table1.Edit;
      Table1.FieldByName('Family').AsString:=S;
      Table1.Post;
    end;
  end;

  
  Вас больше не будут волновать проблемы, связанные с тем, что модули ссылаются друг на друга перекрестно - этого не будет никогда, модуль, в котором размещена GetSomeData никогда не узнает про модуль, в котором размещен Button1Click. Это ему просто не нужно. Мало того, такая процедура может импортироваться из DLL без каких бы то ни было ограничений, помимо передачи строк типа String, но их легко обойти, передавая PChar, или прочитав комментарий, вставляемый средой при генерации проекта DLL.
  
• Вопрос, связанный с тем, что лучше передавать - список параметров, или одну запись или массив - сугубо риторический. В ряде случаев выбора вообще не остается. Когда Вы создаете поток средствами WinAPI (BeginThread на самом деле), то Вы обязаны либо уместить все параметры в один 32 разрядный параметр, либо передавать структуру. Во всех остальных случаях выбор между записью (массивом) и списком параметров диктуется личными предпочтениями программиста. Мне нравятся записи. Их легко копировать одной командой (например, с целью резервного хранения), их можно передавать в несколько разных процедур не раздувая кода. Например, пусть у нас есть программа для сложения двух чисел (трвиально, не правда ли?). Пусть мы хотим разнести ее на три модуля - ввод данных, расчет и печать отчета. Тогда при списке параметров мы будем иметь нечто такое:
  

  if InputData(Data) then try
    CountData(Data);
    PrintReport(Data);
  except
    PrintException(Data);
  end;

  
  При использовании списка параметров код будет чуть длиннее:
  

  if InputData(A,B) then try
    CountData(A,B,C);
    PrintReport(C);
  except
    PrintException(A,B);
  end;

  
  Здесь мы видим плюсы и минусы каждого метода. Плюс первого метода - во все процедуры передается одно и то же, с ним процедуры и работают. Это сродни объектно-ориентированному программированию, когда данные и обрабатывающий их код инкапсулирован в единое целое. На двух параметрах и одном результате это практически незаметно, но когда параметров станет много, плюсы этого метода становятся очевидными. Минус - передача лишних данных, например, в InputData неявно передается переменная С, которая будет хранить результат, хотя для ввода данных она явно излишня. А в PrintReport передаются входные параметры, которые там явно ни к чему (хотя с этим можно поспорить). Еще один минус - с точки зрения "черного ящика", у неправильно написанной процедуры в случае передачи списка параметров меньше шансов угробить входные данные - они будут передаваться как константы, тогда как при передаче записи подпрограмма может испортить все данные, или скомпрометировать их, если они являются секретными. Лучшим решением является комбинация этих двух способов. Настройки, с которыми работает подпрограмма, должны находиться в одном параметре (типа TFormatSettings), входные данные - в другом (передается как константа), а выходные - в третьем (передается как out параметр). Это обеспечивает достаточно хорошую защищенность от сбоев, хотя от компрометации данных и не защитит.
  
• >>> Стоит ли передавать параметром компонент
  Нет, это излишне жесткое ограничение. Желательно, чтобы процедуры обработки не знали, откуда данные, даже если понятно, что "из лесу, вестимо". Желательно обрабатывать не файлы, а потоки TStream, это обеспечит максимальную универсальность. А процедуру для обрабоки файла я обычно делаю с тем же именем, перекрытую (overload), чтобы упростить себе жизнь.

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

procedure TForm1.Button1Click(Sender: TObject);
begin
  ChooseCustomer(tblOrder.FieldByName('CustomerId'));
end;

// Добавляем новый модуль, пусть будет Unit3, и прописываем
// его в Uses Unit1 и Unit2
unit Unit3;

interface

type
  TPr = procedure(var S: string);

var
  _ShowForm,
  _GetText: TPr;

implementation

end.

// Unit2 - модальная форма
procedure GetText(var Text: string);
procedure ShowForm(var Text: string);

var
  Form2: TForm2;

implementation

{$R *.dfm}

procedure TForm2.FormCreate(Sender: TObject);
begin
  _GetText:=GetText;
  _ShowForm:=ShowForm;
end;

procedure GetText(var Text: string);
begin
  Text:=Form2.Edit1.Text;
end;

procedure ShowForm(var Text: string);
begin
  Form2.ShowModal;
end;

// Unit1 - главная форма
procedure TForm1.Button1Click(Sender: TObject);
var
  S: string;
begin
  _GetText(S);      // Просто вызываем процедуру из Unit3
  ShowMessage(S); 
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  S: string;
begin
  _ShowForm(S);
end;