On Tue, Dec 20, 2011 at 12:59 AM, Nicholas Bishop <[email protected]> wrote: > 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?
I tried setting the margin to 80 and conforming to it where possible, but think we cant really do this in many files, so 120, but 80 if authors wish - is fine by me. > Other things: > +1 to no space between keyword and open paren Not too fussed either way, tho have been writing spaces recently, if others prefer no space, I'm not fussed. > -1 to star at the beginning of each comment line Still prefer star. > 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.) I'm not really fussed either way, +1 for picking one. > 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. -1 for switching tabs to spaces, mainly because Its a fairly big change, thought we already had a tab-width of 4 defined somewhere. > 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 -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
