在Forth中定义单词时，选择参数顺序的一般规则(经验法则(是什么？
例如，在控制几个伺服的情况下，让我们定义SERVO!，它将设置伺服通道的位置。
按照!的方式，它应该是: SERVO! ( val #ch -- )，但另一方面，: SERVO! ( #ch val -- )看起来不是更原生吗？
如何选择参数顺序？好问题！在第四章中，这个问题也应该包括结果的顺序。
显然，任何规则都应该有一些理由。它们可以是一些基本原则的结果，也可以解决一些问题。
我认为我们可以从代码重用(任何源代码片段，包括任何单个单词(的便利性开始。这种便利性的主要形式部分是一致性和源代码最小化。
关于论点顺序，这些部分具有以下含义。
- 一致性：我们应该在相似的情况下使用相似的顺序(更正式的：在相似的例子中保留一些实质同构(
- 最小化：我们应该选择一个最小化所有源代码的总词法大小的顺序(实际上，正确的顺序应该最小化堆栈操作的总数(
因此，首先，我们应该与现有的约定(或现有的代码(保持一致，其次，找到最佳排序。当然，当在某些必需的旧代码中已经使用了不一致的约定时，也可能存在例外。
一些已知的惯例可以在著名的"；思考；Leo Brodie的书。其中两个如下。
让地址位于计数之前(提示4.18(
示例：ERASE ( addr u -- )
让来源先于目的地(提示4.19(
示例：MOVE ( source destination count -- )
还有一条众所周知的规则，它不仅是一种惯例，也是一种优化(经实践证实(：
让不太永久的参数位于更永久的参数之前。
通常情况下，它会导致较少的堆栈操作。这个规则可以在许多标准单词中找到。例如，WRITE-FILE ( addr u file-id -- ior )或SEARCH-WORDLIST ( addr u wid -- 0 | xt flag )——其中file-id和wid比addr u对更持久。更永久的参数往往保存在顶级变量中，因此更容易将它们作为顶级参数传递。示例：... GET-CURRENT SEARCH-WORDLIST ...
这条规则也隐含地反映在Leo Brodie 的以下提示中
- 在确定通过数据结构而不是通过堆栈处理哪些参数时，请选择更永久或表示当前状态的参数。(提示7.3(
在出现结果的情况下，此规则变为反规则。
对于退回的项目，将永久性项目放在永久性项目之前
例如，ior、flag等通常在顶部返回。
变更
在某些情况下，有几种变体是很方便的。例如，众所周知的单词ROT和-ROT。其他示例：
the different order of input paramenters
for-list-node ( i*x list xt -- j*x )
foreach-list-node ( i*x xt list -- j*x )
the different order of output parameters
split ( sd-txt sd-key -- sd-txt false | sd-left sd-right true )
split- ( sd-txt sd-key -- sd-txt false | sd-right sd-left true )
您提到的: SERVO! ( val #ch -- )的!方式可能是最好的，因为在计算您希望伺服移动到的值时，您不需要在心里跟踪您正在使用的伺服。
此外，由于它类似于!(将值存储到伺服中(，并且将单词命名为SERVO!，因此如果参数顺序与!相反，则会令人困惑。