Member Avatar for Cudmore

Hey!
This is a "style" question.

Is there some defined custom for the order in which parameters are given to a function, or does it depend entirely on the programmer's stylistic preference? What if the developed software should be released to other programs to incorporate in their own programs? Obviously the parameters should be passed in some logical order.. Take the following two cases, for example:

[function] writeDataToFile (FileName, Data) {}
[function] writeDataToFile (Data, FileName) {}

Which one is preferred? Does it matter? I know the first example is the one which is typically used when passing a file name with data, but, if I, as a programmer [and an artist], were to use the second case, would I be an aberration?

:p

  • 3 Contributors
  • 2 Replies
  • 117 Views
  • 6 Hours Discussion Span
  • Latest Post Latest Post by WaltP

Dani AI

Generated

As said, there is no single universal rule — consistency and documentation matter most. As pointed out, match the conventions already used in the codebase or platform the library will live in. Those two principles will save more confusion than any specific ordering choice.

Practical, widely useful rules of thumb:

  • Put required inputs before optional ones. Defaults belong at the end so callers can omit them.
  • For "operate on a resource" functions, place the resource/target (the thing being acted on) before the payload. That makes intent clear.
  • Group related parameters together and put modifier/flag parameters last. If flags proliferate, prefer an options struct/object or named parameters.
  • Keep the parameter list short (3 or fewer is ideal). If a call needs many parameters, wrap them in a single parameter object to improve readability and future compatibility.
  • In languages that support named/keyword args, order is less critical; still prefer the logical order above for readability.

A short illustration (logging-style signatures):

# clear: target/context first, then message, then optional modifiers
write_log(target, message, level='INFO')

# less ideal for positional-only callers: message before the target
write_log(message, level='INFO', target='app.log')

Notes and cautions:

  • Public, positional APIs are hard to change later; choose an order that anticipates common use and future options.
  • Follow ecosystem conventions for libraries (e.g., idiomatic patterns in Python, C, .NET) so callers find the API familiar.
  • Document every parameter and give examples. Documentation plus consistent ordering is what makes an API pleasant to use — not a single "correct" order.

Recommended Answers

All 2 Replies

Member Avatar for Narue

>Does it matter?
Not really, as long as you're consistent and document the functions.

Member Avatar for WaltP

I agree, it doesn't really matter on an individual basis.

The thing to keep in mind is the other functions in the system. How do they order similar function params.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.