Coding Style Guide, Commit Policy and GIT migration

Development Coding synfig
1

Lately (and fortunately) there are more people involved on Synfig development apart of the main ones (thanks to everyone), so I think that it is time to define a Coding Guideline and a Commit Policy similar to what other successful projects have already done.

I know that in other posts this have been discussed this but nothing has been agreed at the end.

I would like to define, with the agreement of the most amount of people possible, the following items:

  1. The need to have a Commit Policy. It would define the following items:
    1.1) The platform to use for patches registration and for its approval.
    2.2) The people who can decide whether a patch is acceptable or not. Also the basic rules for acceptability or rejection.

  2. The need of a Coding Style Guide. It would allow new or current coders to keep a clean & consistent code. It would define some of the items that you can find here in the Blender Coding Guideline.

  3. Definitively decide to go to git or not. I would like to open the git discussion again because I think that at the end git maintain is better and easier than svn. In the wiki there is a git workflow written in the source page.

So these are my thoughts:

  1. The platform for patches registration and approval depends on the repository type. I don’t know if the review board for synfig admits patches in git style. Currently it doesn’t and I don’t know if that can be changed. SF patch tracker admits any kind of patches since it hasn’t a diff view interface like the review board. If we continue with svn we can stick to review board. It is slow but gives more flexibility for reviewing and for approval. For patch approval I have not a preliminary idea rather than a patch should be approved if none is against it. After a prudential time after the patch is requested for review, it can be approved if none has something against. Obviously people that has not approval rights cannot see its patch approved until someone approves it and commit it to the repository. We should write something similar to this.

  2. Definitively we need a Coding Style Guide. I propose to define only some of the entries of the Blender one and if needed expand them to more detailed. So initially I propose:

-Tabs and spacing.
-Parenthesis.
-Multiple statements on one line.
-Writing comments.
-Variable and function names.
-Environment variables naming.

  1. Regarding to git migration. I’m for the migration but still confused about how should it work.
    Current git repository keeps separated ETL, synfig-core and synfig-studio gits. repo.or.cz/w/synfig.git. I think it is better to have them all in the same git repository instead of three separated ones. Large modifications are easier to do there. Also I like the current idea of wiki and gitosis repos to keep track of all the changes.

I would like to see a heated discussion about those points. It would tell us what’s the current synfig health. :slight_smile:

-G

2

Hi!

As I’ve been recently working with the code, I just want to give my two cents:

  1. For the coding style, I suggest almost the same as Blender:
  • Tabs or Spaces: Tabs!
  • Parenthesizing: K&R
  • Multiples statements in one line: Only in very specific cases.
  • Writing comments: For me, // comments are good. Also, you need them for variable / enumeration documentation in Doxygen.
  • Variable and function names: As this one is very tricky to change in existent code, I suggest to go with the underscore separation of variables.
  • Environment variables naming: I suggest using the same as for now, something like “SYNFIG_” for the prefix of environment variables.

Also, if you have to use an integer to store a pointer for whatever reason, use a long, because if you don’t code won’t work on 64 bits systems.

Maybe I’m not saying anything new, but I think it’s better to write down, just like you said on that post Genete pointed out.

  1. I also vote for git usage. Offline support it’s great, and it’s faster (at least for pulling).

As I’ve said, just my two cents :wink:

3

I’d split them up into separate repositories. We can create a master repository that includes the three repositories as submodules so working with three separate repositories is not more complicated at all. Tagging and creating releases would also be done in the master repository. This pretty much ensures that you are creating releases from the versions you intend to.

4

Yeah, maybe the solution it’s to use separated repos with submodules, that’s great. I’ll vote for it to, so everyone is happy :slight_smile:. If you want to use only one repo, you can check it out, and if you want the three repos, you could pull the main repo with submodules.

Good idea, Bombe :wink: