From: Mike Nordell (email@example.com)
Date: Thu May 11 2000 - 10:42:37 CDT
A couple of questions that surfaced.
Though I haven't seen it in AbiWord coding recommendations, I presume we
try to keep it within 80 columns? If so, we might as well add it to the
coding recommendations document.
To the same doc we possibly want add:
Try to live by the LORD principle ("Locality Of Reference
Documentation"). The further away the doc is the less probable it is that
someone reads it. I.e. if you add a method that by its name isn't
obvious what it does, you might want to add some extra info in the
header file. If you feel it needs even more explanation, please forward
that explanation to the implementation files comment.
I for one found some calls confusing, not knowing whether a parameter was
an [in], [out], or [in, out] parameter (expressed in RPC terminlogy, but
you get the gist). In some places, like the well used mapXYToPosition()
method, I've also come to think "this method should really _return_ a
value (read lightweight class) rather than taking a bunch of "[out]"
arguments the way we used in the "good ol' C days".
If no one have anything against this I'd like to make some changes along
This is actually a problem with C++ vs. C. In C you _had_ to make it a
pointer to make it an [out] parameter, but int C++ you can make that
parameter a (non-const) reference and to the caller it just looks like a
normal parameter". By just browsing the code you never know if a
parameter gets changed or not. This is IMO bad. But, one could easily
turn this into a struct/class that gets returned to the caller. If anyone
is concerned about the performance penalty of copying this data back,
there's something called "Return Value Optimization" (RVO) that takes
care of this (it gets "allocated" by the caller and passed as a hidden
parameter to the callee, the same as what happens today in the mentioned
/Mike - please reply to AbiWord-dev only
This archive was generated by hypermail 2b25 : Thu May 11 2000 - 09:42:18 CDT