大部份情况下，开发者设计参数时仅关注函式中如何使用参数，忽略客户端的易用性，因而使客户端唿叫或阅读函式时，对于引数的提供感到不便、困惑甚至误解。参数并非只是函式与客户端的资料参考，设计时可退一步为客户端着想，让参数成为函式与客户端「沟通」的桥樑。
最理想的函式是单参数函式，这样客户端就不需要烦恼如何提供引数。实际上，客户端经常需要提供引数以查询结果，使用引数来转换资料，或是产生与引数对应的副作用，然而在考虑增加参数的个数时，应多思考客户端在唿叫或阅读时是否理解。
增加参数个数时，应避免的考量之一，是要求客户使用旗标（Flag）。以单参数函式为例，客户端提供true时做一件事，提供false时又做另一件事，当开发者处于函式实作中，虽可从流程中清楚瞭解旗标变数的意义，然而客户端对于refresh(true)这样的程式码，可能看不出true的意涵，改为asyncRefresh()与syncRefresh()两个函式，会是比较清楚的作法。
如果函式中完全根据参数值来执行不同流程，也许拆开为数个不同函式会比较好，像是使用setValue(HEIGHT,100)设定高度，setValue(WIDTH,150)时设定宽度，不如改为setHeight(100)、setWidth(150)来得清楚。直接将函式结果传给另一函式作为引数，或许也非必要，在《Refactoring:ImprovingtheDesignofExistingCode》书中10.8提到的例子是，像discountedPrice(basePrice,getDiscountLevel())这样的程式码，可改为直接在discountedPrice中唿叫getDiscountLevel()，客户端使用discountedPrice(basePrice)会比较清楚。
如果函式使用超过一个以上的参数，而参数之间有关联性，则可建立参数物件（ParameterObject）来包装它们，这样参数个数就可减少。例如设定外框时，使用setOuterBounds(x,y,width,height)，不如使用setOuterBounds(bounds)来得清楚，好处不仅是减少了参数个数，在《ImplementationPatterns》书中，KentBeck还谈到「很多功能强大的物件，都是从参数物件开始逐渐成长起来」，像是需要将外框扩大时，就可使用setOuterBounds(bounds.expand(-2))的程式码让意图更清晰。
如果参数非得超过一个，那么参数顺序就至关重要，顺序基本上以不违反自然应有的组合为原则，像指定范围时，begin会在end之前，lower会在higher之前。如果参数间沒有自然的顺序，那就参考现有惯例或制订惯例，透过训练来熟悉顺序。
以有序清单为例，将物件加入清单中指定索引处时，第一个参数通常是索引，第二个参数是被加入的物件；在《CleanCode》书中，举assertEquals(expected,actual)为例，这也是得使用熟悉一段时间，才不至于搞错两个参数的顺序。
有的函式会有必要参数与可选（Optional）参数，后者通常会在沒有使用者沒有指定引数时提供预设值，常见惯例是必要参数在可选参数之前，有的语言在定义参数时可指定预设引数（Defaultargument），最好也遵守此惯例，严谨的Python会在必要参数定义于预设引数之后产生错误，然而自由度高的Ruby允许这么定义，这是因为Ruby有它自身的惯例，使用者指定的引数会优先分配给必要参数，多馀引数才依序分配给有预设引数之参数。对于Java这类不支援预设引数的语言，可使用重载（Overload）来弥补，惯例上具备最少参数的重载版本，上头的参数就是必要参数，而其他的重载版本，前面的参数要与具备最少参数的版本应当相同。有些语言唿叫函式时可用关键字引数（Keyargument），例如Python可在唿叫函式时，以set_point(y=10,x=10,z=20)的方式，此功能建议用来更直觉地表达可选参数，而非使用于必要参数的指定。
有些语言不支援预设引数，然而有适当的资料结构，可用来定义可选物件（Optionalobject），以JavaScript为例，可以传给函式{x:10,y:20}这类的物件，既然称为可选物件，就代表该物件提供的特性都是可选的值，函式内部会在某特性从缺时提供预设值。不要将参数物件与可选物件混为一谈，参数物件中的参数都是必要的，必要参数不应混在可选物件中，例如draw_circle(radius,{x:10,y:20})，表示radius是必须的，而x、y会是可选的。
有的语言支援可变长度引数，虽然从客户端来看，可以提供函式任意数量的引数，然而，基本上函式就是使用单一参数来接受引数清单，使用上建议对清单中的引数平等看待，不要有特定顺序问题。接受可变长度引数的参数，应该在必要参数与具备预设引数的参数（可选参数）之后。
如果参数非得超过一个，那么参数顺序就至关重要，顺序基本上以不违反自然应有的组合为原则，像指定范围时，begin会在end之前，lower会在higher之前。如果参数间沒有自然的顺序，那就参考现有惯例或制订惯例，透过训练来熟悉顺序。
以有序清单为例，将物件加入清单中指定索引处时，第一个参数通常是索引，第二个参数是被加入的物件；在《CleanCode》书中，举assertEquals(expected,actual)为例，这也是得使用熟悉一段时间，才不至于搞错两个参数的顺序。
有的函式会有必要参数与可选（Optional）参数，后者通常会在沒有使用者沒有指定引数时提供预设值，常见惯例是必要参数在可选参数之前，有的语言在定义参数时可指定预设引数（Defaultargument），最好也遵守此惯例，严谨的Python会在必要参数定义于预设引数之后产生错误，然而自由度高的Ruby允许这么定义，这是因为Ruby有它自身的惯例，使用者指定的引数会优先分配给必要参数，多馀引数才依序分配给有预设引数之参数。
对于Java这类不支援预设引数的语言，可使用重载（Overload）来弥补，惯例上具备最少参数的重载版本，上头的参数就是必要参数，而其他的重载版本，前面的参数要与具备最少参数的版本应当相同。有些语言唿叫函式时可用关键字引数（Keyargument），例如Python可在唿叫函式时，以set_point(y=10,x=10,z=20)的方式，此功能建议用来更直觉地表达可选参数，而非使用于必要参数的指定。
有些语言不支援预设引数，然而有适当的资料结构，可用来定义可选物件（Optionalobject），以JavaScript为例，可以传给函式{x:10,y:20}这类的物件，既然称为可选物件，就代表该物件提供的特性都是可选的值，函式内部会在某特性从缺时提供预设值。不要将参数物件与可选物件混为一谈，参数物件中的参数都是必要的，必要参数不应混在可选物件中，例如draw_circle(radius,{x:10,y:20})，表示radius是必须的，而x、y会是可选的。
有的语言支援可变长度引数，虽然从客户端来看，可以提供函式任意数量的引数，然而，基本上函式就是使用单一参数来接受引数清单，使用上建议对清单中的引数平等看待，不要有特定顺序问题。接受可变长度引数的参数，应该在必要参数与具备预设引数的参数（可选参数）之后。
在提供引数给函式时，通常是作为函式执行时的输入，如果函式会产生结果，通常是预期以传回值方式取得。不过有时可见到，函式会改变输入的引数状态，像是Python的sort函式，会直接改变传入的list物件为排序状态，一般来说不鼓励输出用的引数，因为违反唿叫时，引数是作为函式输入的预期，如果不希望使用输出用引数，可像Python使用sorted函式来传回新的list物件，作为排序后的结果。
一个不当使用的情况是，为了突破函式传回值只能是单一值或型态的限制，想在一次函式唿叫中取得多个结果，像是希望在函式唿叫后，想要同时取得大于及小于某数的两个数列，因而传入两个list作为输出用的引数。这当中须检讨：该函式是否做了两件以上的事，是否可拆开为两个函式分別负责；如果想传回两个以上的值或型态，可用元组（Tuple）或自定义物件来包装，而非靠输出用引数。
不过，在《ImplementationPatterns》中举了个收集参数（CollectingParameter）的例子，KentBeck提到：「有时计算逻辑需要从多次的方法唿叫中收集结果，并将这些结果以某种方式合併起来」，若合併方式有一定的复杂度，那么使用一个参数来收集结果就较为直觉了，像是在JUnit中，使用TestResult来收集测试结果就是实际案例，因为它必须在多个Test实例的runTest方法中收集测试结果。
如果必须得改变物件状态，像sort这类的函式，似乎很难避免输出用引数的方式，如果程式採用物件导向典范，可将这类函式定义为物件本身的方法，像是Python中使用[1,2,3,4].sort()，就可避免使用输出用引数，因为，物件本身（self，其他语言中可能是this）状态就取代了输出用引数。
实际上，在《Refactoring:ImprovingtheDesignofExistingCode》书中，虽然有时沒有明确指出，但在考虑到物件状态时，往往可以减少参数的使用，该书讨论第一章的案例时，发现Customer类別的amountFor方法有个接受Rental实例的参数，却沒有使用来自Customer的资讯或方法，而将amountFor方法重构至Rental类別，也就不再需要任何参数。
在讨论API设计时，开发者往往仅着重设计模式、架构与各种设计原则的实现，以让程式更有弹性且可维护，却较少考虑到参数设计，实际在身分转为唿叫函式的客户端时，不良的参数设计经常发生困扰。所以，在专注于函式实作之后，应该经常转换为客户端角度，检视一下参数设计是否造成客户端与函式间的沟通不良，或者是使用上的不便。
因在网路上经营「良葛格学习笔记」（openhome.cc）而闻名，曾任昇阳教育训练中心技术顾问、甲骨文教育训练中心授权讲师，目前为自由工作者，专长为技术写作、翻译与教育训练。喜好研究程式语言、框架、社群，从中学习设计、典范及文化。闲暇之馀记录所学，技术文件涵盖C/C++、Java、Ruby/Rails、Python、JavaScript、Haskell等多个领域。