Jan Holesovsky wrote:
> As to the crossing the line - the first time it won't let you commit,
> and you'll be angry, the second time it won't let you commit, and you'll
> just fix that, and the third time you'll comment just naturally, and
> won't even hit the check :-) This worked with the warnin
On Fri, 2010-12-03 at 17:34 +0100, Miklos Vajna wrote:
> On Fri, Dec 03, 2010 at 11:14:12AM -0500, Kohei Yoshida
> wrote:
> > My rationale: Many times when I work on feature branches, I commit stuff
> > but intentionally not provide documentation because the role of the
> > class/method/whatever
On Fri, Dec 03, 2010 at 11:14:12AM -0500, Kohei Yoshida
wrote:
> My rationale: Many times when I work on feature branches, I commit stuff
> but intentionally not provide documentation because the role of the
> class/method/whatever may change during the course of the
> implementation. This requi
On Fri, 2010-12-03 at 11:08 -0500, Kohei Yoshida wrote:
> On Fri, 2010-12-03 at 10:23 +0100, Jan Holesovsky wrote:
> > Hi all,
> >
> > On 2010-12-02 at 21:59 +0100, Thorsten Behrens wrote:
> >
> > > So just in case, let's agree to disagree & keep the patches coming!
> > > :)
> >
> > As a conclus
On Fri, 2010-12-03 at 10:23 +0100, Jan Holesovsky wrote:
> Hi all,
>
> On 2010-12-02 at 21:59 +0100, Thorsten Behrens wrote:
>
> > So just in case, let's agree to disagree & keep the patches coming!
> > :)
>
> As a conclusion, what about to combine Miklos' check for the missing
> documentation w
Hi Miklos,
On 2010-12-03 at 16:19 +0100, Miklos Vajna wrote:
> > That's why I highlighted that this would be done only with _new_ files,
> > ie. the files that have have been git add'ed, and did not exist in the
> > repository before. And we can further limit that only to .hxx/.h.
>
> Ah, that
On Fri, Dec 03, 2010 at 03:04:55PM +0100, Jan Holesovsky wrote:
> That's why I highlighted that this would be done only with _new_ files,
> ie. the files that have have been git add'ed, and did not exist in the
> repository before. And we can further limit that only to .hxx/.h.
Ah, that makes a
Hi Wol,
On 2010-12-03 at 13:43 +, Wols Lists wrote:
> >> I find it surprising me actually saying this, but - for the while, I
> >> think this would be crossing the line of solving a social problem
> >> by technical means. ;)
> > Additionally I'm not aware of a method to tell doxygen to check
Hi Miklos, Thorsten,
On 2010-12-03 at 13:11 +0100, Miklos Vajna wrote:
> > I find it surprising me actually saying this, but - for the while, I
> > think this would be crossing the line of solving a social problem
> > by technical means. ;)
>
> Additionally I'm not aware of a method to tell doxy
On 03/12/10 12:11, Miklos Vajna wrote:
> On Fri, Dec 03, 2010 at 11:14:54AM +0100, Thorsten Behrens
> wrote:
>> I find it surprising me actually saying this, but - for the while, I
>> think this would be crossing the line of solving a social problem
>> by technical means. ;)
> Additionally I'm no
On Fri, Dec 03, 2010 at 11:14:54AM +0100, Thorsten Behrens
wrote:
> I find it surprising me actually saying this, but - for the while, I
> think this would be crossing the line of solving a social problem
> by technical means. ;)
Additionally I'm not aware of a method to tell doxygen to check ju
Jan Holesovsky wrote:
> As a conclusion, what about to combine Miklos' check for the missing
> documentation with a commit hook, so that it does not allow you to
> commit _new_ files without (at least the high level) documentation? ;-)
>
Hi Kendy,
I find it surprising me actually saying this, but
Hi all,
On 2010-12-02 at 21:59 +0100, Thorsten Behrens wrote:
> So just in case, let's agree to disagree & keep the patches coming!
> :)
As a conclusion, what about to combine Miklos' check for the missing
documentation with a commit hook, so that it does not allow you to
commit _new_ files with
Hi Lubos,
you wrote:
> I'm not asking for anything ridiculous like having a paragraph
> explaining every line, I'm saying that everything non-trivial
> should have at least some documentation
>
Good, then we're mostly on the same page. Then we're both talking
about mission statements, higher-level
On Wednesday 01 of December 2010, Thorsten Behrens wrote:
> ok, so let me elaborate my (maybe extreme) point a bit.
>
> Documentation is a crutch, a feeble attempt to help us mere humans
> to grok big code bases. Good code needs only few comments, because
> it speaks for itself - it may need some m
> Why not drop merging from OOO after LibO 3.3?
Because there is still a significant number of people working on OOo, and they
are in many cases the best experts there are on the code they are working on,
and they are doing significant and useful improvements? Because there is no
licensing rea
Beware - I am a newcomer - maybe my point of view is quite wrong due to
lack of understanding. But then at least I will understand something
better :- )
My first remark: stepping in seems to me to be very difficult despite
the very friendly behaviour of people here.
> un-documented code-base is a
Lubos Lunak wrote:
> See? So nobody actually knows what the code really does, and everytime
> somebody changes something there, they possibly have a slightly different
> understanding of the purpose, resulting in even bigger mess. That's yet
> another advantage of documentation - even you yours
On Wed, 2010-12-01 at 14:25 -0500, Kohei Yoshida wrote:
> But I've already become immune to this hard-to-figure-out code base, so
> I stopped thinking that way years ago. I've even trained myself to
> ignore those German comments. When I see functions, I see chunks of
> code, not functions. ;-)
On Wed, 2010-12-01 at 13:37 +0100, Lubos Lunak wrote:
> On Wednesday 01 of December 2010, Thorsten Behrens wrote:
> > see? That's what I meant, documentation for most of the higher-level
> > methods is either
> >
> > a) superficial
> > b) so much prose that you're better off debugging the code in t
On Wed, 2010-12-01 at 01:22 -0700, Tor Lillqvist wrote:
> I am sure it is not hard to find people who think the OOo code APIs
> are elegant, consistent and intuitive. And they would be equally
> right.
Well, I've been working on OOo (and now LibO) code base roughly about 6
years now, and I haven't
>> Personally I think it would be very nice if source files had just a few
>> lines of comment telling what they are about, from a very high perspective.
>> Every time I am searching for the implementation of some functionality in
>> the OOo/LO codebase, I find myself looking at source files with v
On Wednesday 01 of December 2010, Thorsten Behrens wrote:
> see? That's what I meant, documentation for most of the higher-level
> methods is either
>
> a) superficial
> b) so much prose that you're better off debugging the code in the
>first place
>
> (bFull has *a lot* of side effects, and no
On Tuesday 30 of November 2010, Thorsten Behrens wrote:
> Hi Lubos,
>
> adding documentation for what you describe doesn't help much, if at
> all. Core API is reasonably documented, see offapi/udkapi/sal/basegfx.
What is core API then? Do things under e.g. libs-core count as well? If yes,
then j
On Wednesday 01 of December 2010, Tor Lillqvist wrote:
> > After having years of experience using a nice, intuitive
> > and well-documented APIs (Qt,KDE),
>
> But surely you should realize the causality here? It is exactly your years
> of experience with them that makes Qt and KDE seem nice and int
Sebastian Spaeth wrote:
> What does bFull mean? Not so quick? What portions will be formatted if
> this is FALSE? Looking at the function it either calls
> pImpEditEngine->FormatFullDoc();
> or
> pImpEditEngine->FormatDoc();
>
> What the heck is the difference between those functions? Now I h
> After having years of experience using a nice, intuitive
> and well-documented APIs (Qt,KDE),
But surely you should realize the causality here? It is exactly your years of
experience with them that makes Qt and KDE seem nice and intuitive.
It is extremely hard, probably impossible, to come u
On Tue, 30 Nov 2010 18:50:17 +0100, Lubos Lunak wrote:
> On Tuesday 30 of November 2010, Thorsten Behrens wrote:
> > Additionally, I think most classes don't necessarily need detailed
> > docs for all methods in the first place (which may also hurt later
> > merging from OOo), but would already be
Lubos Lunak wrote:
> On Tuesday 30 of November 2010, Thorsten Behrens wrote:
> > Additionally, I think most classes don't necessarily need detailed
> > docs for all methods in the first place (which may also hurt later
> > merging from OOo), but would already benefit from a two-line
> > "mission st
On Tue, Nov 30, 2010 at 04:21:08PM +0100, Thorsten Behrens
wrote:
> Miklos Vajna wrote:
> > Does the idea sounds sane, OK to push?
> >
> Totally!
OK, pushed.
> Would you maybe also be interested to work on an improved
> start page / index, e.g. like this here:
>
> http://www.informatik.uni-ha
On Tuesday 30 of November 2010, Thorsten Behrens wrote:
> Additionally, I think most classes don't necessarily need detailed
> docs for all methods in the first place (which may also hurt later
> merging from OOo), but would already benefit from a two-line
> "mission statement" at class level (of c
Miklos Vajna wrote:
> Does the idea sounds sane, OK to push?
>
Totally! Would you maybe also be interested to work on an improved
start page / index, e.g. like this here:
http://www.informatik.uni-hamburg.de/~meine/hg/vigra/file/bf402d01f821/docsrc/index.dxx
(see
http://www.informatik.uni-hambur
32 matches
Mail list logo
