Re: Help to get started
- To: Parin Porecha <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: Help to get started
- From: Jonathan Nieder <firstname.lastname@example.org>
- Date: Sat, 29 Dec 2012 10:35:22 -0800
- Message-id: <20121229183522.GA2631@elie.Belkin>
- In-reply-to: <CAOrFX2Fuk584LLBramBFkto+mRs_9PseF=WiJdGztEnaboZgfw@mail.gmail.com>
- References: <CAOrFX2Fuk584LLBramBFkto+mRs_9PseF=WiJdGztEnaboZgfw@mail.gmail.com>
Parin Porecha wrote:
> I am new to this group and I would like to contribute to this community.
> So, in order to solve bugs, I need some help to get started.
Thanks for your interest.
If you'd like an exercise to start, I'd suggest writing a patch to
split one of the larger functions like archivefiles() or
process_archive() into smaller logical steps. Follow the advice from
the Linux coding guidelines:
| Functions should be short and sweet, and do just one thing. They should
| fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
| as we all know), and do one thing and do that well.
| The maximum length of a function is inversely proportional to the
| complexity and indentation level of that function. So, if you have a
| conceptually simple function that is just one long (but simple)
| case-statement, where you have to do lots of small things for a lot of
| different cases, it's OK to have a longer function.
| However, if you have a complex function, and you suspect that a
| less-than-gifted first-year high-school student might not even
| understand what the function is all about, you should adhere to the
| maximum limits all the more closely. Use helper functions with
| descriptive names
You will probably want to refer to the Debian policy manual for
background, and we're here, too, if you have any questions.
In the meantime you might come up with questions that can be solved
by reading the source or simple improvements to dpkg, and you can work
on those in parallel if you like. :)
Hope that helps,