kicad-developers team mailing list archive

[Marc Jacobi <obiwanjacobi@xxxxxxxxxxx>]

Yes, I agree that bug fixing or adding simple features is a good way to ease into the code (complexity).
But I was hoping there would be some abstract picture of how the program is structured (internally - that it has modules is pretty evident on the outside) what components are identified and how the responsibilities are distributed among the classes...?
Documentation at class level (doxygen) is nice for reference - when you already know where to look and what to look for...For getting to know a code base it is too much and too detailed IMHO...
Marc

From: oe.nick@xxxxxxxxx
Date: Wed, 4 Mar 2015 10:45:49 +0100
Subject: Re: [Kicad-developers] Getting started?
To: obiwanjacobi@xxxxxxxxxxx
CC: kicad-developers@xxxxxxxxxxxxxxxxxxx

Den 04/03/2015 10.03 skrev "Marc Jacobi" <obiwanjacobi@xxxxxxxxxxx>:

>

> Hi,

>

> I am Marc Jacobi from the Netherlands and I want to get involved. 

> I have found the source code but its rather overwhelming.

>

> Is there any documentation on the code architecture and/or patterns used?I am not sure about architecture, but for patterns... there is the coding style policy [1], although I am not sure that is what you mean.

> Or anything on concepts and interaction?I hope other devs has better answers than me, but there is also the KIWAY stuff with an overview on [2].

> What would be a good place to start...?
A good place to start is fixing bugs reported on the bug tracker, that leaves you with a starting point for exploration. It is very often better to have to have some goal, like a new feature to add or a problem to solve when digging into new stuff.
>

> Thanx,

> Marc

>[1] http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_coding-style-policy.html[2] https://github.com/KiCad/kicad-source-mirror/wiki/Modular-KiCad-with-Alternate-Top-Level-Launchers