--===============1021699844== Content-Type: multipart/alternative; boundary="----=_Part_5646_23099688.1128427535919" ------=_Part_5646_23099688.1128427535919 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 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 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 > ------=_Part_5646_23099688.1128427535919 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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,in= heritance heirarchy plus many other things.

I think, codes must be documented, but kicker is not a mess.

On 03/10/05, Wade O= lson <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 on= ly
gives you UML, something's grossly wrong.  The name alone t= ells 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 Octob= er 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 ref= ine the
> > code.
>
> high level code documentation is= excellent for helping people do design
> recovery (which happens whe= n learning a new code base as well as hunting for
> design issues 6 months after having written something yourself ;).= i would
> welcome an ongoing documentation of plasma as it takes sha= pe.
>
> on the flip side, i find uml nearly useless for describ= ing new design concepts
> as it says everything about structure to me and almost nothing abo= ut the
> 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 22= 09 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> Full = time KDE developer sponsored by Trolltech (http://www.trolltech.com )
>
>
>
__________________________________________= _____
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel

------=_Part_5646_23099688.1128427535919-- --===============1021699844== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline _______________________________________________ Panel-devel mailing list Panel-devel@kde.org https://mail.kde.org/mailman/listinfo/panel-devel --===============1021699844==--