Строки в отдельном файле .pas

Перемещение строк в отдельный файл — хорошая идея! Он удерживает их вместе и позволяет легко менять их при необходимости. В вашем вопросе не говорится, что вы хотите иметь возможность их переводить, но централизация поможет в этом.

Но код типа:

Messages.Add(sMsgText1 + '' + sName + '' + sMsgText2 + '' + sFullPath)

не лучше, чем такой код:

Messages.Add('The voucher was NOT sent to ' + sName+
                      ' because the application is in TEST MODE.');

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

Во-вторых, причина перемещения строк, чтобы сохранить связанные элементы вместе и упростить их изменение. Что, если вы хотите изменить приведенное выше сообщение, чтобы вместо «Файл 'foo' в пути 'bar'...» оно звучало как «Файл bar\foo is...»? Вы не можете: способ построения сообщений по-прежнему фиксирован и разбросан по всему коду. Если вы хотите изменить несколько сообщений, чтобы они были отформатированы одинаково, вам нужно будет изменить множество отдельных мест.

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

Рефакторинг на шаг впереди

Вместо этого я бы предложил более агрессивный рефакторинг вашего кода сообщения. Вы определенно на правильном пути, когда предлагаете перенести сообщения в отдельный файл. Но не просто перемещайте строки: перемещайте и функции. Вместо большого количества Messages.Add('...'), разбросанных по коду, найдите общее подмножество создаваемых вами сообщений. Многие будут очень похожи. Создайте семейство функций, которые вы можете вызывать, чтобы все похожие сообщения были реализованы с помощью одной функции, и если вам нужно изменить их формулировку, вы можете сделать это в одном месте.

Например, вместо:

Messages.Add('The file ' + sFile + ' in ' + sPath + ' was not found.');
... and elsewhere:
Messages.Add('The file ' + sFileName + ' in ' + sURL + ' was not found.');

имеют одну функцию:

Messages.ItemNotFound(sFile, sPath);
...
Messages.ItemNotFound(sFileName, sURL);

Ты получаешь:

• Централизованные строки сообщений
• Централизованные функции сообщений
• Меньше дублирования кода
• Более чистый код (без сборки строк в вызове функции, только параметры)
• Легче перевести — предоставьте альтернативную реализацию функций (не забывайте, что простого перевода подстрок может быть недостаточно, вам часто нужно иметь возможность существенно изменить формулировку.)
• Четкое описание сообщения в имени функции, например ItemNotFount(item, path), что приводит к
• Более понятный код, когда вы его читаете

Звучит неплохо :)

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

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

unit Strings;

resourcestring
  strMsgText1 = 'The voucher was NOT sent to ';

etc...

Но такую ​​строку, вероятно, лучше сделать так:

resourcestring
  strVoucherNotSent = 
    'The voucher was NOT sent to %s because the application is in TEST MODE.';
  strVoucherForNHasValueOf =
    'The voucher for %s has a value of $%.2f'; 

Преимущество этого в том, что в некоторых языках расположение и порядок таких замен отличается. Таким образом, переводчик может размещать аргументы там, где это необходимо. Конечно, приложение должно затем использовать Format() для обработки строки:

Messages.Add(Format(strVoucherNotSent, [sName]));
Messages.Add(Format(strVoucherSavedTo, [sFullPath]));
Messages.Add(Format(strVoucherForNHasValueOf, [sName, dblValue]));

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

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

Как правило, вы должны спросить, каковы преимущества такого серьезного рефакторинга, и если они не очевидны, то вы вполне можете что-то менять только ради изменений.

Если вы хотите перевести свое приложение, рассмотрите возможность использования Gnu GetText для delphi, также известного как dxGetText. Это лучше, чем помещать ваши строки в отдельный файл .pas, потому что это позволяет вам включить перевод без каких-либо специальных инструментов, какой-либо перекомпиляции, даже конечными пользователями.

Что ж, консенсус здесь, кажется, склоняется в пользу стороны, и я полностью с этим согласен. Неправильное чрезмерное использование строковых литералов может привести к тому, что ваш источник получит строковую типизацию.

Одно преимущество, которого мне все еще не хватает, — это повторное использование строк. Хотя это не прямая выгода от переноса в другой модуль, а от переноса строковых литералов в константы.

Но довольно существенным недостатком является необходимое время для создания этого отдельного исходного файла. Вы можете применить этот хороший метод программирования в следующем проекте. Это полностью зависит от того, есть ли у вас достаточно времени (например, хобби-проект) или крайний срок, есть ли у вас следующий проект или нет (например, студент), или вы просто хотите немного попрактиковаться. Как и ответы и комментарии David H, как и все решения, которые вы сделать, вы должны взвесить преимущества.

Помимо всех видов причудливых инструментов рефакторинга, которые могут обеспечить некоторую автоматическую помощь, поймите, что перемещение строковых литералов в другой модуль само по себе не выполняет работу. Как Руди и David M уже ответил, вам частично придется переписать исходный код. Кроме того, поиск удобочитаемых, коротких и применимых имен констант требует времени. Поскольку во многих комментариях уже говорилось, что контроль над правописанием согласованности важен, мне нравится думать, что тот же аргумент применим и к самой замене констант.

Что касается ответов на перевод, независимо от того, применимы ли они к OP или нет, перемещение всех ваших исходных строк в отдельный блок является лишь частью решения для перевода. Вы также должны позаботиться о дизайнерских строках (т. е. заголовках) и совместимости с графическим интерфейсом: более длинный перевод все равно должен поместиться на вашей этикетке.

Если у вас есть роскошь или необходимость: сделайте это. Но я бы взял это на следующий проект.

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

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

(*) использование dxgettext в «общих» каталогах.