I'm basically fine with this proposal. Don't know if it's worth enforcing completely, but if that's the way we want to go I wouldn't object to a commit hook enforcing it.
On breaking long lines, this is probably the only thing I care strongly about. I find it very helpful to split my editor into multiple views to show source files displayed next to each other, and long lines make this harder to do. I prefer we keep to 80-char limit; if others see this as not practical, perhaps we could say hard-limit is 120, but 80 is preferred where reasonable? Other things: +1 to no space between keyword and open paren -1 to star at the beginning of each comment line Small notes on indentation: 1) Some switches in Blender have the cases indented (so the case bodies are double indented from the switch() block), others have the cases lined up with the switch(), might want to bless one of these styles (my vote would be to the second style.) 2) If we really are going to start changing all the code to conform to a new style, might be worth switching C code to all spaces rather than tabs + spaces for aligning wrapped lines. Then we avoid the whole tab-width question. If not, at least the recommended tab width should be specified in the coding standard. Thanks, -Nicholas On Mon, Dec 19, 2011 at 8:34 AM, Sergey Sharybin <[email protected]> wrote: >> >> I prefer no space, don't see why there should be a difference because >> one is a keyword and the other a function call, it's still just an >> arbitrary choice. But I can live with the proposed coding style up to >> now. >> > > It's just more matter of readability which is a bit subjective and > unfortunately it can't be solved in a way everybody is happy of it. I might > only collect opinions of developers and prepare proposal based on it. > Unless Ton tell "if must be no space here" i can't force the whole comunity > to switch to this style. > > Another inconsistency is in variable/function/struct/macro names. The >> rules there tend to be variables lowercase (often without _ separator >> but not always), functions also lower case (with _ separator) except >> for the module prefix, structs camel case starting with capital >> letter, and macros all uppercase (with _). >> > > Yes, and it's not only remained inconsistency.Will continue collecting them > and documenting next two-three days (depening on how i'll be busy with > other tasks) . > > I'd love to see existing code changed to enforce all this, and >> personally wouldn't mind it adding an extra step to svn blame, but not >> everyone might agree with that. >> > Yes, switchig existing code code to new style will reduce confusages of > code style. But it might be a bit pain for branches and i think it might > worth of separating such kind of refactor, so there wouldn't be a task for > one developers only. > > Another question i've got is related on code style in intern/. My opinion > that we shouldn't be strict about libs from there, but be more about > "following this code style in intern/ is really welcome". Maybe somebody > have got another opinion here? > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
