Re: [fluid-dev] Coding style (was: More commits)

[josh]

Quoting David Henningsson <address@hidden>:
> I can live with almost everything I'm not very annoyed with people using
> different coding styles. But when I write code I will most certainly
> make mistakes, how will we solve that? Perhaps I will have to run
> "indent" or similar program before I commit?


I don't think we need to be too serious about it really.  If someone  
checks in code that doesn't conform to whatever standard we decide on,  
anyone else should feel free to format things correctly.  Running  
indent on code changes would probably help though too.  We should  
probably try to keep commits that deal with formatting and ones that  
change functionality separate, so that one doesn't have to scan  
through purely aesthetic changes to find what functionally got changed.


> I think I personally scan for "name(" to easily see what is a function
> call and not a variable.

Its easier for me to spot "function_name (var1, var2, etc)" which is  
why I like to put a space between the function name and its parameters.

> Is there a rule like "If a file is more than 2000 lines we should
> consider splitting it in two"? Personally I like to keep my files 1000
> lines or shorter, but for this project it doesn't matter much. And if
> that means we will get many more source files, perhaps source
> subdirectories could be considered.


There is no rule currently in regards to max lengths of files.  I  
think if a file gets relatively large (1500 lines or so) and there is  
a pretty clear logical division that can be made, then splitting it  
would be good.  I have also been thinking that source directories  
might be helpful for organizing the code.  At a minimum a separate  
directory for all driver related source files, since it can be  
difficult to differentiate between those and core synthesis files if  
one is not familiar with the project.  There aren't a huge amount of  
files though, so we can probably just let it be for now.


> Another thing is max columns per line. Do we keep it at 76/80 chars and
> then a new line, or how long lines do we allow?

I think it is good to keep it around max 80 chars, but some overflow  
is OK.  If code starts getting crammed up against the right side, it  
probably means the code could use some redesign.


> > Voting summary:
> > - No tabs (Pedro, Josh and David)
> > - 4 space indentation (Pedro, Josh 2 or 4, David doesn't care)
> > - Return type on separate line from function (Pedro and Josh)
> > - Space between type and '*' (GThread *) (Pedro and Josh)
> > - Braces on same line as previous statement except procedures (Pedro
> > and David)
> > - Additional statements line up with '(' and '[' (Pedro and Josh)
>
> If we want consistency, perhaps "majority of existing FluidSynth code"
> should have a vote as well? Or are you planning to autoindent all the
> existing code?

I was planning on auto-indenting the whole lot and manually going  
through and correcting problem areas.  That is why I was mentioning it  
would be good to get it out of the way now, early in this development  
cycle.  To minimize the amount of functional changes that have  
occurred before the re-formatting point.

> // David

Josh