[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Soc-coordination] GSOC idea for next year: undusting some packages



On Wed, Oct 01, 2008 at 10:03:24PM +0200, Michael Vogt <mvo@debian.org> was heard to say:
> That is a good idea. I created a (initial) page on
> http://wiki.debian.org/Teams/Apt - everyone is welcome to add to it :)

  Thanks!

> The difference between the ubuntu and debian development is basicly
> the different release schedules. I merge stuff into my personal
> development tree, stuff gets merged into the debian-sid tree, stuff
> gets merged into the ubuntu tree. Because the ABI is so fragile,
> certain stuff is kept out longer in one tree than the other, but both
> branches are closely releated. 

  I wonder if we should look into making the ABI less fragile in the
future.  Of course, the stuff around the cache, where we use a lot of
inlining, probably needs to be exposed -- but I'm sure that there are
some parts of the library where we can use the virtual interface /
implementation technique to bury the details of each class in its .cc
file.

  I think it would be useful to have a "coding guidelines" section in
the wiki with things like this.  The idea would be to write new code
to the current guidelines, and brush up old code when we touch it.
Other things we could list there:

    * Write doxygen API documentation for all classes and functions.
      I've found this to be a huge help, even with code on solo
      projects.  It's a useful reference later, and it also is a good
      sanity-check of your APIs (I find that if you can't write clear
      documentation of a function, it's a good indication that it's
      poorly designed).

      Of course, it also gives you a jump on real API documentation
      (although you usually need some higher-level doxygen blocks
      to tie it all together).

    * If you have a container object with iterators, give it an
      STL-style interface unless you have a reason not to.

    * Make methods const unless (again) you have a reason not to.
      But virtual functions probably shouldn't be const.

    * Don't introduce global variables that are exposed to client code.

    * what else?

  Daniel


Reply to: