[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] kicker is a mess
From: Vinay Khaitan <vkhaitan () gmail ! com>
Date: 2005-10-04 12:05:35
Message-ID: 56c534770510040505u4fadea06v () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
As far as kicker code is concerned, I think, a code comprehension tool can
be easily used for this purpose.
In kdevelop, you can import kicker and see all its inheritance diagram.
In source-navigator, you can have much better view of all
crossreference,inheritance heirarchy plus many other things.
I think, codes must be documented, but kicker is not a mess.
On 03/10/05, Wade Olson <wadejolson@gmail.com> wrote:
>
> True, which is why UML is considered one of many artifacts in software
> development.
>
> If you're an architect and the only thing you transfer to your
> programmers: UML, or if you're a programmer and your designer only
> gives you UML, something's grossly wrong. The name alone tells you
> what it is, otherwise it'd be UDL: Unified Description Language.
>
> Like XML or similar, old-schoolers condemn it, marketers promote it as
> a holy grail, and the pragmatic see it as just another tool and apply
> it where userful.
>
>
> On 10/3/05, Aaron J. Seigo <aseigo@kde.org> wrote:
> > On Monday 03 October 2005 08:24, Wade Olson wrote:
> > > To me, UML diagrams allow for both better introductions to new
> > > participants, as well as helps more experienced people to refine the
> > > code.
> >
> > high level code documentation is excellent for helping people do design
> > recovery (which happens when learning a new code base as well as huntin=
g
> for
> > design issues 6 months after having written something yourself ;). i
> would
> > welcome an ongoing documentation of plasma as it takes shape.
> >
> > on the flip side, i find uml nearly useless for describing new design
> concepts
> > as it says everything about structure to me and almost nothing about th=
e
> > why's and wherefore's implied by the design. which is to say: what the
> person
> > creating that design was thinking at the time.
> >
> > --
> > Aaron J. Seigo
> > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
> >
> > Full time KDE developer sponsored by Trolltech (http://www.trolltech.co=
m
> )
> >
> >
> >
> _______________________________________________
> Panel-devel mailing list
> Panel-devel@kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
[Attachment #5 (text/html)]
As far as kicker code is concerned, I think, a code comprehension tool can be easily \
used for this purpose.<br> In kdevelop, you can import kicker and see all its \
inheritance diagram.<br> In source-navigator, you can have much better view of all \
crossreference,inheritance heirarchy plus many other things.<br> <br>
I think, codes must be documented, but kicker is not a mess.<br><br><div><span \
class="gmail_quote">On 03/10/05, <b class="gmail_sendername">Wade Olson</b> <<a \
href="mailto:wadejolson@gmail.com">wadejolson@gmail.com</a> > \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">True, which is why UML is \
considered one of many artifacts in software<br> development.<br><br>If you're an \
architect and the only thing you transfer to your<br>programmers: UML, or if you're a \
programmer and your designer only<br>gives you UML, something's grossly \
wrong. The name alone tells you <br>what it is, otherwise it'd be UDL: \
Unified Description Language.<br><br>Like XML or similar, old-schoolers condemn it, \
marketers promote it as<br>a holy grail, and the pragmatic see it as just another \
tool and apply<br> it where userful.<br><br><br>On 10/3/05, Aaron J. Seigo <<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br>> On Monday 03 \
October 2005 08:24, Wade Olson wrote:<br>> > To me, UML diagrams allow for both \
better introductions to new <br>> > participants, as well as helps more \
experienced people to refine the<br>> > code.<br>><br>> high level code \
documentation is excellent for helping people do design<br>> recovery (which \
happens when learning a new code base as well as hunting for <br>> design issues 6 \
months after having written something yourself ;). i would<br>> welcome an ongoing \
documentation of plasma as it takes shape.<br>><br>> on the flip side, i find \
uml nearly useless for describing new design concepts <br>> as it says everything \
about structure to me and almost nothing about the<br>> why's and wherefore's \
implied by the design. which is to say: what the person<br>> creating that design \
was thinking at the time. <br>><br>> --<br>> Aaron J. Seigo<br>> GPG \
Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 \
DB43<br>><br>> Full time KDE developer sponsored by Trolltech (<a \
href="http://www.trolltech.com">http://www.trolltech.com \
</a>)<br>><br>><br>><br>_______________________________________________<br>Panel-devel \
mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/panel-devel"> \
https://mail.kde.org/mailman/listinfo/panel-devel</a><br></blockquote></div><br>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic