Re: gEDA-dev: Good software engineering practices for gEDA

[Ivan Stankovic <ivan_dot_stankovic-at-NOSPAMfer_dot_hr>]

On Sun, May 27, 2007 at 07:45:13PM +0100, Peter TB Brett wrote:
> On Sunday 27 May 2007 19:00:08 Ivan Stankovic wrote:
> > This is a possibility, but what would be the advantage over atexit?
> >
> 
> You could make some Scheme interface to it, so you could have arbitrary Scheme 
> code called on exit.
> 
> (gschem-exit-hook (lambda () (display "I'm an exit hook!")))
> 
> It would be very nice to have a general mechanism for hooking onto events like 
> exiting gschem, in case it's needed for work in the future.  In addition, 
> it's very clear to the person reading the code *exactly* when and where the 
> hook will be called, which is actually very important.

Alright, that makes sense. But I have no experience with Scheme and
don't know how to interface it with C, which means I would be a bad
candidate to do it. If you're willing to do this, I would be happy to
amend my patch. 

> Ivan, I'm a little bit troubled by the code you've been submitting.  Although 
> it clearly works -- and works well -- and there's nothing technically *wrong* 
> about it, some of the things you've done seem a bit hackish.
> 
> For instance, gschem didn't support dynamic menus declared using the Scheme 
> extension mechanism, but you needed this for the recent files menu.
> 
>  - Nice way of doing it: add support for dynamic menus directly to the
>    menu-generating mechanism by registering Guile procedure callback
>    functions, changing the way it works if necessary.  Then use new features
>    to implement recent file lists.  (And then a "Pages" menu, "Recent
>    Symbols", etc, etc).
> 
>  - Your way of doing it: use a magic string in menu list, which is magically
>    substituted in the C code.  It works, but it works for that feature and
>    only that feature.

I completely agree with you here, and everything what you said below. I myself 
consider some of my code ugly and wrongly designed. However, let me point out
several things. 

Firstly, I'm a newcomer to gEDA development so I really don't have the 
confidence it takes to do major changes to the code base, like your component 
library changes, for example. Keep in mind, I'm still getting familiar
with the code. Second, gEDA choosing Scheme for an extension language
means I can't touch the code in many places since I don't have any
Scheme experience. 

Third, looking around gschem code I'm not really impressed by the code 
quality; grepping for '#if 0' ends up with around 80 matches (that's for 
gschem alone!). There are also design issues that desperately need fixing 
(I'm currently looking at status bar message implementation -- i_basic.c 
obviously needs major cleanup). There are even functions that are just
sitting there, without obvious usage. With code like that, it really is
hard to do something clean and well designed -- you just have to put put 
up with what's already there. Unless, of course, you're willing to
redesign/reimplement big chunks of code, and this gets me back to the
first point.

Fourth, and this is probably the most important point, I consider
gEDA development (somewhat) slow. Now, I understand there is obvious lack
of developers and existing ones don't have much time to spend. But I
really don't want to make major changes and then maintain them in my
own private branch for a possibly long period of time. Rather, I would
like to do incremental, self-contained patches that get tested well
and applied reasonably quick (here I must thank you and Peter Clifton
for all the help with my patches so far). 

Currently, I think the way development here works is: someone has some
changes ready, requests testing the relevant patches, few people
check that things go well, the code gets merged and then Ales makes a
new release. This is all fine, but I'd love to see more users come
and test development features, since sometimes (often?) a bug is found only
after the release. When you see more users testing your feature, you
also have a way to tell if the feature is useful to others, not just
for yourself. And this also tells you if you're adding bloat to the
code (more on that below).

Lastly, I think switching main SCM system from CVS to git would really benefit 
us all (come on people, git isn't any harder to grasp than CVS).

> People who understand the gEDA code base are few -- I don't even pretend to 
> know how everything works outside my areas of interest -- so developer time 
> is at an absolute premium.  

Exactly. And that's why I stick to areas I'm familiar with: C and GTK.

> Making sure that current developers' time is well 
> spent, and attracting new developers to the project, both require the code 
> base to evolve in ways that ensure that not only does code do what you expect 
> it to, but also that new features and capabilities added are designed in as 
> generally useful way as sensibly possible.

Ever heard of overengineering? 
Also, "perfect is the enemy of good", or something like that?

> I've tried hard to work in this way in my work on the component library, and 
> this has meant that I've been able to add a lot of quite cool new features 
> with special cases very well contained, and that I now have a clear roadmap 
> for even more awesome things I can put in with a minimum of new code needing 
> to be written (in fact, hopefully I'll be able to *remove* some of the code 
> from libgeda's C source).

Sure, I generally like that thinking, but when it comes to implementation, I 
always choose the simplest and cleanest design that does all that is needed.
Remember, KISS principle. That's the way software engineering should be
done, not thinking up all the things you _could_ do with the code. I
find it _much_ easier to add more functionality when the underlying
design is simple, I'm sure you'll agree.

Yes, we _could_ implement many fancy features but, for every feature, we should 
first ask

(1) is it _really_ needed?
(2) what impact does it have on code complexity?

Otherwise, you just end up with bloat. And that implies bad design.

> Please don't take this criticism to personally; it's something I think many 
> people need to think about, not just you (or me).  It's been brewing in my 
> mind for the last few weeks, and has only really bubbled to the surface now.

This also applies to me and this mail. Don't take this personally.

-- 
Ivan Stankovic, ivan.stankovic@fer.hr

"Protect your digital freedom and privacy, eliminate DRM, 
learn more at http://www.defectivebydesign.org/what_is_drm"


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev