means: few arguments

Reader: I'd like the soup, please.

Bim: I'll need your username and password. If you don't remember, your security question is 'favorite soup'.

public functions

Public functions-- those available to the rest of the system-- are easier to reuse if they don't require lots of arguments. Otherwise, a following coder encounters something very like a painful bureaucracy.

Bim: I'd like to paint my garage.

Helpful attendant: Go to room 505 and get a form requisition form. Request form 202 and deliver it to room 808. When they get back to me I can tell you what other forms you'll need.

With too many requirements, it's tempting to build without a permit. In code, that means duplicating functionality. Be lazy the right way-- don't write twice what you can figure out how to write once.

If lots of data is needed, use a context. It's a briefcase with copies of every form you've ever so far provided-- which are the ones you usually need. It's really a context that defines a code module (briefcase label: "The story of me painting things").


Class constructor initialization can be automated if there are few (or, ideally, no) requirements, although they must appear in a working state.

opposite: private functions

Private functions are completely different.

This is your sandbox-- make what you need, prune later.

opposite of the opposite: private variables

Private variables are completely different.

Don't pass data around this way. Reader can't look at any one function and guess what's in it. Better to pass what's needed to interior functions, wherever possible. Here, the "few arguments" case doesn't apply.

see also

short functions and small classes. 2017 [171108]