[Bf-committers] Newbie point of view: variable declaration and readability

Christian Hubert christian.hubert at dstribe.com
Tue May 8 20:26:43 CEST 2018




First, sorry for this long email. I know 2.8 is the nowadays focus, but I
cannot be a newbie twice (or.).


During a port to 2.8, I was asked to keep in place some variables
declarations (Sybren, nothing personal about that, it is just to understand
what should be done or not as this is not mentioned in code style).


So I did the port as wanted (at least, I hope).


But my though is "this is not good". Here are the reasons why:


A very simple example (original code):


<start of the example >

    DerivedMesh *dm_other;


    if (!bmd->object)

        return dm;


    dm_other = get_dm_for_modifier(bmd->object, ctx->flag);

<end of the example >


We have a " dm_other " floating in the air and which could or not be
used/instantiated later. 


If we want to tell a story that could be:


*	I want to tell you about a DerivedMesh which is called dm_other
*	Oh. but wait. Anyway if my data does not know an object I quit
*	Oh. but if not, dm_other is now a nice derived mesh




If we rewrite that:


<start of the example >

    if (!bmd->object)

        return dm;


    DerivedMesh *dm_other = get_dm_for_modifier(bmd->object, ctx->flag);

<end of the example >


The story is now:


*	Anyway we need to have an object or we quit
*	But as we stay there, here is the story of a derived mesh called
dm_other which is a nice derived mesh


Well, some could think this makes few difference. But:


*	In larger code you need to remember variable names and types which
are declared previously and used/instanciated (or not) much later
*	When they are instanciated, knowing their types is not always
*	Code is more verbose, divided
*	Direct comprehension and maintenance is harder
*	Eventually some code parts won't be run for some reasons/conditions
and these declarations will be useless
*	Variable instantiation/initializaition is not guaranteed


So. maybe what I'm saying here is not so important. Anyway the code will run
and do the job. But I really believe this is part of code quality (as
nowadays compiler accept that instead of declaring everything at the
beginning of each function) and we need to remember that "a code is written
once, read very often, modified sometimes".


And I also believe this kind of big and great project (I mean Blender)
depends only on people will and all that leads to the straight (more simple)
way to understand and do things, the more effective participants will be
(sorry for my bad english, I hope this is understandable).



So now, If we come back to the 2.8 port:


OK the port needs to be as straight as possible: we don't want side effects
in these circumstances.


But in the other hand, if we don't change now, we will never change. or is
there "code quality only" (not features bound) revision steps? I do not



Well. I hope this email can be constructive. If it is not from your
feedback, I'll stop this kind of things. But, if it is considered
constructive, I will post more about my newbie first steps in this
(fantastic but so hard) new world.


If you want more, the next "newbie point of view" could be: "Which API or
API level should I use?"



Kind greetings,




More information about the Bf-committers mailing list