[Bf-committers] Restricting code cleanup

Sergey Sharybin sergey.vfx at gmail.com
Sun Dec 30 11:24:47 CET 2012


>
> * Small-localized cleanups in areas of the code that are being updated.
> For example, while updating text editor syntax highlighting I found
> some of the code a bit cryptic and did some cleanup commits.
> Example of small-localized edits: r53416, r53418
>

If it's just cryptic but doesn't affect on current work you're doing, still
would say better to ensure with maintainer there's no work going on there.
The thing is -- there could be larger project with improvements to this
area, which will not only get rid of cryptic code, but also will change
logic of this code. That'd be confusing if logic would be changed to less
cryptic in trunk after someone changed logic around it completely in a
branch.

What i mean is -- for as long function is not needed for your current work
and not buggy, don't change it. At least at bcon1-2. And making functions
less cryptic should be better communicated with maintainers (not talking
about text editor cleanups which in this case are fine, but in general).


> * New code that doesn't follow our code style guide is fine to cleanup.
> Example: r53405
>

Would be completely fine if cleanup is done relatively soon.


> * Unusual cases where function is in-fact named wrongly (found a
> _set() function that was in fact 'getting' a while back, right next to
> a _get function that was getting too :) ), as long as this isnt used
> in 100s of places, renaming should also be fine.
>

Ouch, this is indeed bad naming. In this case for sure re-naming is nice i
think. But perhaps renaming like adding module prefix and other naming
changes better not be done before current projects are merged in and be
better communicated with maintainers (whos list is still not
updated, unfortunately :( ).

And do compile blender with default features enabled after renaming :)

-- 
With best regards, Sergey Sharybin


More information about the Bf-committers mailing list