Refactor Reorder Parameters

[CategoryRefactoring/RefactoringLanguage]

If you find 'f(a,c,b)' inconvenient, change it to 'f(a,b,c)' -- along with reversing the last two parameters of all calls.

Why would you want to do this?

• Some languages require optional parameters to be last. So if you find that most callers provide a "default", "zero" or "this parameter not really provided here" value for 'c' above, then 'c' has to appear after 'b' in the parameter list to be made optional: 'f(a,b,c=0)'

• It may make the code easier to read. Change 'f(first,last,middle)' to 'f(first,middle,last)'.

But beware:

• If several parameters have compatible types, the compiler won't tell you when some callers are providing parameters in the wrong order.

---

From "The little book of basic style: How to write a program you can read." by John M. Nevison, 1978 AddisonWesley ISBN 0201052474

"RULE 14: Make the line flow left to right."

"Western language since the time of the Greeks has read left to right, so direction is always lurking behind the order of the line. Take advantage of your reader's predisposition whenever possible."

(The illustration is of a window painter painting "SALE" on the inside of a window -- oriented so that HE can read it. A confused passerby, seeing the backwards "ELAS" is visibly confused.)

---

JohnCarter posted on the Yahoo Refactoring list:

A typical progression might be...

 A::f( Thing t, Thong tt, That ttt)
 A::g( Thong tt, That ttt)
 B::h( Thong tt, That ttt, Thing t)
 C::i( That ttt, Thong tt)

refactored to....

 A::f( Thing t, Thong tt, That ttt)
 A::g( Thong tt, That ttt)
 B::h( Thing t, Thong tt, That ttt)
 C::i( Thong tt, That ttt)

Then considering for a while all the recurrences of Thing, Thong, That and consider making a

 class ThongThing? : public Thong {
  Thing t;
  That tt;
 }

 A::f( const ThongThing?& t)
 A::g( const ThongThing?& t)

and perhaps...

 ThongThing?::h( const B& b)

and

 C::i( ThongThing?& t)