Re^3: Deriving meaning from source code, some code is self documenting

Ah, but at least in most of those cases the programmer would still have to write something to describe the data you are pulling out: The bare data itself isn't all that useful. (What does it mean?)

Whereas the inheritance and dependencies are useful even (or especially) when simply listed. So at least there's a reason for drawing a line there. ;)

Comment on Re^3: Deriving meaning from source code, some code is self documenting

Replies are listed 'Best First'.
Re^4: Deriving meaning from source code, some code is self documenting by Mutant (Priest) on Dec 09, 2008 at 17:40 UTC
True, but you might be able to get something from the variable names. e.g. `sub foo { my ($needle, @haystack) = @_; ... }` [download] Having those available might be useful (of course you can read the source as well, but you might want to see that from a different module).	[reply] [d/l]
Re^5: Deriving meaning from source code, some code is self documenting by DStaal (Chaplain) on Dec 09, 2008 at 18:00 UTC
Might. It's on the slope of diminishing returns, though. (And the numbers of different ways to get variables out of the arg array is huge.) Parent classes and dependencies are machine-document able, fairly easily. They are conceptually similar. And documenting them for a human is usually copy-paste-format in my experience. Trying to automatically document functions may be useful, but it wouldn't be something I'd want to run with the dependency tree. (Which I would want to run on every module I've ever written: It'd make my life simpler.) Functions I'd rather do by hand, usually. (I guess I'm looking at this as a way to document my code, not code someone else has written that I want to use.)	[reply]