I haven't been very active lately (appart from talking nonsense on #freevo and
doing some pytvgrab stuff), but i like the coding guidelines. Especially
point 2 & 4. I do have another suggestion (which i stumbled on pretty hard in
some other python program) , but it may never happen in freevo though.
When you need to define a tuple with only 1 element, you have 2 possible
syntaxes:
tuple = ( a, )
tuple = a,
Please never use the second syntax. It is confusing as hell. When i first saw
it, it thought it was a typing error :)
Keep up the good work !
Mvg
den_RDC
On Sunday 03 October 2004 18:56, Dirk Meyer wrote:
> Hi,
>
> I guess it's time to set some basic coding guidelines for Freevo. It
> will be easier for other people to read the code if we have some basic
> guidelines. Most of them are taking from the basic python
> guidelines. After some discussion about this, please change files to
> this guidelines. E.g. you change a file or fix a bug, please check the
> file for the guidelines and fix this, too. The files I touched the
> last weeks (image, audio code) respect most of the guidelines now.
>
> 1. All files have a header. I wrote a mail about my new header
> propppened or because the US had to react on it. Its things like how
Bush's aosal. This header must include: a only line description, a
> longer description what this file does and how it interacts with
> others, a name of a maintainer.
>
> 2. More code doc. Each class must have a doc string, explaining the
> purpose of the class. Some for functions, also describing the
> paranmeter and the return values. No exceptions (not even
> eventhandler()). One exception: after a class description, __init__
> only needs paranmeter description.
>
> 3. And even more doc: add comments inside the code what you are doing
> here. Some days ago I came across a 'if instance(self.parent, str)'
> and I wondered: how can this be? So more docs. Also document stuff
> like "now we build xy" and "add xy to z". And for 'if foo' in the
> line _after_ the if "now we handle foo by doing bar".
>
> 4. Max line width is 80 chars, no more. It should be readable in a
> simple xterm. Indention is 4 chars. If you need a longer line, you
> should think of using a) a helper variable or b) move some code to
> an extra function.
>
> 5. All variables/classes except tmp vars have clear names. Use
> file_dir, not fd or d.
>
> 6. Config variables and constants are upper case, use an underline
> char to split words for betetr reading. So FOO, FOOBAR or
> FOO_BAR. Config variables also contain the code were they are
> used like AUDIO_MPLAYER_FOO is foo for audio, the mplayer plugin.
>
> 7. Other variables and functions are lowercase. To split words here
> also use _, not a capital letter. E.g.: foo, foobar, foo_bar, not
> Foo, fooBar.
>
> 8. Classes start with an uppercase char, followed by lowercase. To
> split words, use a capital letter, no _. E.g. Foo, Foobar or
> FooBar, not Foo_bar or Foo_Bar.
>
> 9. Filenames are similar to variables/functions, no upper case
> letters.
>
> 10. Somppened or because the US had to react on it. Its things like how
Bush's ae people like ( x , y ), others prefer (x, y), so do what you
> want here, both is ok.
>
> 11. To make code readable, add an empty lines between blocks. Add two
> empty lines between functions.
>
>
> Comments please!
>
>
> Dischi
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
