Re:The Code Documentation Fallacy
by bookface on Thursday October 17, 2013 @01:20PM
(#6566730)
Agreed completely about how awful dynamic languages can be in this respect. I've found what helps a lot is consistent naming of parameters. For example, numberOfWidgets (an integer) versus widgets (a collection) or file (a file handle) versus path (a string).
[ Parent
| on HN ]
Sure, consistent naming helps a lot (though I'm partial to short-yet-readable alternative like widgetCounts). Sadly, sometimes ambiguity is unavoidable. And other times, you're just dealing with bad code.
But consistent naming does not help with the "optionality" of parameters.
Re:The Code Documentation Fallacy
by acjohnson55 on Friday October 18, 2013 @01:08AM
(#6569870)
In that sense, dynamic languages often have a jump on their functional counterparts. Relying on the type annotations for all documentation is probably the other side of the coin. I understand that generic combinators sometimes need sufficiently general argument names, but even then, there's often some semantic meaning that can be attached with a self-documenting variable name. Enough with the 1- and 2-letter variable names!