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

[Ivan Stankovic <ivan_dot_stankovic-at-NOSPAMfer_dot_hr>]

On Mon, May 28, 2007 at 12:58:21AM +0100, Peter Clifton wrote:
> > 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!).
> 
> Sounds like a good project ;) Some of them are obsolete debug code (and
> can be removed), some are old unused code (should be removed), and
> occasionally you see a piece of unused code which might be useful - just
> not yet. I've no idea what we should do with those cases.

Now I'm thinking I would be much better off focusing on cleaning up
existing code before adding new features. I think I will just do
that.

> On the other hand, sometimes we must accept the "quick" solution, where
> we recognise it - and what would be the ideal solution, in order to make
> the code work. Perhaps we should make a Wiki page of code we've "tripped
> over" that wants attention though.

Yes, that would be useful.

> Users must be compelled to test beta releases by the promise of killer
> features. No user really cares about testing back-end refactoring. Add
> to this the pain of installing new versions (often unavailable in any
> distro's main repositories), and we see why the uptake is slow.

That is why I am so eager to add new features quickly. It attracts more
users, testers and, hopefully, developers. Unfortunately, the resulting
code (design) isn't very nice, as you have noticed.

> > And this also tells you if you're adding bloat to the
> > code (more on that below).
> 
> My ideal patch a) fixes bugs  b) Does so whilst reducing the line-count
> (So long as its not a cheating reduction of line-count such as skimping
> on comments!) Line count of new features in new files isn't so important
> I don't think, but certainly a lot of existing stuff can be simplified.
> Complexity breeds bugs!

I absolutely agree.

> Recognising that we can't just implement such plans overnight, (and
> trying to avoid the trap you mention) we're working on both incremental
> changes which help to tidy up parts of the code, and user-visible
> features which help keep people interested in new versions. The long
> term goals are still present of course.
> 
> Perhaps some sort of road-map which all the devs can contribute to is in
> order?

That would be nice, but I don't expect to have detailed list of milestones
and such. Just a short summary of what people are working on (or intend
to do) would suffice. Perhaps the summary could be regularly sent
to the mailing list so everyone knows where we stand?

Let me begin with my short TODO list:

- Visual feedback when pressing keyboard accelerators 
  (it's working fine currently, but I need to clean up the patch somewhat)

- Finer grid when moving attributes
  (I've not yet begun work on this)

After those are done, I would like to work on other gschem related
projects listed on http://geda.seul.org/gsoc/projects.html.

Sorry for ranting, I'll let the code speak for itself.

-- 
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