字符串在单独的.pas文件中

Jam*_*est 12 delphi pascal

如果不随意移动它,这可能不是这个问题的正确位置.我标记为Delphi/Pascal,因为它是我在atm工作的,但这可能适用于我猜的所有编程.

无论如何,我正在做一些代码清理,并考虑将程序中的所有字符串移动到单独的.pas文件中.这样做有利有弊吗?它甚至值得做吗?

澄清一下:我的意思是我将创建一个单独的文件,Strings.pas中我会创建所有文本字符串变量.

防爆

现行守则

 Messages.Add('The voucher was NOT sent to ' + sName+
                          ' because the application is in TEST MODE.');
 Messages.Add('Voucher Saved to ' + sFullPath);
 Messages.Add('----------------------------------------------------------');
Run Code Online (Sandbox Code Playgroud)

新代码将是这样的:

Messages.Add(sMsgText1 + '' + sName + '' + sMsgText2 + '' + sFullPath)
Run Code Online (Sandbox Code Playgroud)

Strings.pas文件将保存所有字符串数据.希望更有意义

Dav*_*vid 12

将字符串移动到单独的文件是个好主意!它将它们保持在一起,如果需要,可以让您轻松更改它们.你的问题并没有说你希望能够翻译它们,但集中化将有助于解决这些问题.

但是,代码如下:

Messages.Add(sMsgText1 + '' + sName + '' + sMsgText2 + '' + sFullPath)
Run Code Online (Sandbox Code Playgroud)

不是比喜欢代码更好:

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

你已经变成一个混乱,但可读的函数调用到一个混乱和联合国可读的函数调用.使用旧代码(上面的第二个代码段),您可以阅读代码并大致了解消息的内容,因为很多内容都在文本中.使用新代码,你不能.

其次,移动字符串以将相关项目保持在一起并使其更容易更改的原因.如果你想改变上面的消息,而不是在路径'bar'中说"文件'foo',那么该怎么办?"它的措辞是"文件栏\ foo是......"?您不能:消息的构建方式仍然是固定的,并且分散在整个代码中.如果要以相同的方式更改要格式化的多条消息,则需要更改许多单独的位置.

如果你的目标是翻译你的消息,这将是一个更大的问题,因为翻译需要重新编写消息而不仅仅是翻译组件.(例如,您需要更改消息中包含的子项的顺序 - 您不能只假设每种语言都是替换中的短语.)

进一步重构

我建议你更加积极地重构你的消息代码.当您建议将邮件移至单独的文件时,您肯定是在正确的轨道上.但是不要只是移动字符串:移动函数.而不是大量Messages.Add('...')分散在您的代码中,找到您创建的公共消息子集.很多都会非常相似.创建一个可以调用的函数族,以便使用单个函数实现所有类似的消息,如果需要更改它们的语法,则可以在一个位置执行.

例如,而不是:

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

有一个功能:

Messages.ItemNotFound(sFile, sPath);
...
Messages.ItemNotFound(sFileName, sURL);
Run Code Online (Sandbox Code Playgroud)

你得到:

  • 集中的消息字符串
  • 集中消息功能
  • 减少代码重复
  • 更清洁的代码(在函数调用中没有组合字符串,只是参数)
  • 更容易翻译 - 提供功能的替代实现(不要忘记只是翻译子串可能是不够的,你经常需要能够大大改变措辞.)
  • 清楚地描述消息在函数名称中的含义,例如ItemNotFount(item, path),导致的消息
  • 阅读时更清晰的代码

听起来不错 :)


Rud*_*uis 7

我认为将所有字符串常量移动到一个单元是很有意义的.它使文本更容易更改,特别是如果您想要翻译成其他(人类)语言.

但是不是字符串,为什么不做我通常做的事情,即使用resourcestring.这样,您的字符串可以由其他人使用资源编辑器进行更改,而无需重新编译.

unit Strings;

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

etc...
Run Code Online (Sandbox Code Playgroud)

但是这样的字符串可能做得更好:

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'; 
Run Code Online (Sandbox Code Playgroud)

这样做的好处是,在某些语言中,这种替换的位置和顺序是不同的.这样,翻译人员可以在任何需要的地方放置参数.当然,应用程序必须使用Format()来处理字符串:

Messages.Add(Format(strVoucherNotSent, [sName]));
Messages.Add(Format(strVoucherSavedTo, [sFullPath]));
Messages.Add(Format(strVoucherForNHasValueOf, [sName, dblValue]));
Run Code Online (Sandbox Code Playgroud)

  • @David:我完全不同意.我认为它根本不会让人感到困惑.很明显,所有文本都在:单个单元中.在spearate单元中,它们可以按目的或单位分组,并用空行和注释分隔.它还使拼写,语法等更容易一致.IMO,这是一个很好的编程实践.但我们同意我们不同意.人们应该做他们想做的事.我只是想表明它是如何完成的,并且有些人,像我一样,认为它很有意义.您是否注意到RTL和VCL也这样做了? (4认同)
  • 我认为它使维护更容易,或者至少不会更难.他应该使用有意义的常量名称,而不是使用文字字符串.维护文本要容易得多.每个人写一个非平凡的程序应该做的是IMO. (3认同)
  • 在我的答案中,最后一行代码以什么方式存在问题?常量的名称非常清楚文本应该传达的内容,尽管它没有给出确切的文本.对于翻译,其值可能应放在名称之前,这是唯一有用的解决方案.在这种情况下,格式字符串当然应该使用格式来指示在哪里使用哪个参数. (2认同)

Dav*_*nan 5

如果您想将UI翻译成不同的语言,那么您可以将所有文本放在一个文件中,或者可能是一些专门用于声明字符串常量的文件.

但是,如果您在没有这么强烈动机的情况下进行此更改,那么您可能只是难以阅读您的代码.

一般来说,你必须问这样一个重大重构的好处是什么,如果它们不是不证自明的,那么你可能只是为了改变而改变事物.

  • 我认为任何非平凡的程序在一个单独的文件中都有它的常量(尤其是字符串)总是一个好主意.有时必须更改它们,然后在单个文件中找到它们比在应用程序的所有源文件中找到它们要容易得多.不仅对于翻译,而且当我检查所有字符串以便一致地使用单词,逗号等时.使用Delphi IDE中的当前重构功能来执行此操作非常简单. (3认同)
  • 即使没有翻译计划,仍然有时需要更改常量和字符串文字,例如纠正拼写,或者使它们都使用相同的术语,等等.将它们放在一个地方是IMO最好的方法实现这一点.所以可能没有直接的好处,但如果这是一个非平凡的计划,很可能会有长期的好处.尤其是你已经超过6个月没看过的代码很难再次找到,并且在定义的地方放置你的东西会让这些事情变得容易得多,IMO. (3认同)
  • 我认为这很容易.您几乎可以直接复制文本,就像IDE在重构这些字符串时所做的那样,或者您给出了使用它的意图.对于拥有多个单元的程序或专家,我总是这样做.我不认为我的源文件是不可读的.相反:我的常量名称反映了字符串的意图,目的,而不是文字文本.我认为它使源代码非常易读,特别是如果文本很长.长文本会分散实际代码的注意力. (2认同)
  • @david - "改变的好处是否值得?" - 绝对,原因解释.它通常很容易实现,非常值得.充满硬编码字符串消息的代码尖叫'业余'. (2认同)