How to reduce the cognitive load of your code

Re:How to reduce the cognitive load of your code by Retric on Tuesday March 29, 2016 @05:26PM (#11385005)

The question is why you need a helper function? IMO, public functions are a special case and your generally better off using different naming schemes for internal and external functions.

Granted, if it's pure pass-through then reusing the name is a non issue. Foo(x){foo(x);} is not confusing. Foo(x){junk; foo(x);} is.

One option is Foo(x){validateForFoo; ValidedFoo(x);}

Alternatively for private functions JunkFoo(x){junk(x); foo(x);} And replacing JunkFoo with a meaningful name if possible.

Again though, public function Foo(x) should really call internal function Bar(x) otherwise it's really easy to couple things on both sides of an interface.

[ Parent | on HN ]

Re:How to reduce the cognitive load of your code by kazinator on Tuesday March 29, 2016 @09:36PM (#11386366)

The computation represented by "foo" could actually not be contributing any new semantics to "foo". It could just be some boiler plate that is needed to extract and isolate various resources out of context "x", so that these pieces can then be passed to the low-level "foo", which knows nothing of the aggregate "x". "junk" could be some locking an dunlocking, or debugging, or preparing the display in some way or whatever.

If someone wants to know how to name the low-level helper which does the real work and the interface over it, we just have to take it for granted that the separation is necessary and that it makes sense for either function to have the name "displaySortedItems" or whatever.

[ Parent | on HN ]

Re:How to reduce the cognitive load of your code by Retric on Wednesday March 30, 2016 @09:57AM (#11389276)

If your stripping boilerplate then your operating on different things. Which seems more readable?

  SortGuiElement(){junk; SortUserNames(); junk;}
  SortUserNames(){junk;}

vs.

  SortNames(){junk; sortNames() junk;}
  sortNames(){junk;}

It might seem obvious and the code might be identical, but I see the second case very frequently in other peoples code.

[ Parent | on HN ]

Re:How to reduce the cognitive load of your code by kazinator on Wednesday March 30, 2016 @11:36AM (#11390057)

Re-using an identifier with just a case difference is criminal.

You want:

  SortNames(){junk; SortNamesImpl(); junk;}
  sortNames(){junk;}

or whatever: SortNamesGuts(), InternalSortNames(), DoSortNames(), LowLevelSortNames(). Anything but just flipping the case of a letter or two in the "SortNames" identifier.

[ Parent | on HN ]

Re:How to reduce the cognitive load of your code by Retric on Wednesday March 30, 2016 @12:13PM (#11390335)

I agree that reusing the same name with different capitalization is bad, but I have seen this from several developers across many different teams and several languages. These same people often have Foo(x){junk; Foo(x,y,z); more junk;} sure if it's a pass though that's fine but if you have 10 foo('s) that all have internal logic then please come up with some actual names.

Amway IMO, SortNames() and Internal/Do/LowLevel/SortNames() are almost as bad because just looking at the names it's not obvious what's going on. Yes, visually they look different which helps and consistency can make things even more readable. But, even just SortNamesHappyPath() gives some idea of what's going on.

[ Parent | on HN ]