Solved Best coding practices

Hello,

I'm cleaning my code and I have some of questions about the best practices to prevent any cinema 4d app crash.

1 - Is it necessary to check if the object or tag it was created before inserting into the document?

Example:

obj = c4d.BaseTag(c4d.Onull)
tag = c4d.BaseTag(c4d.Tdisplay)

if not obj or not tag:
    return
    
obj .InsertTag(tag)

2- Is there a specific case to use the condition if value is None or if obj_or_tag is None instead of if not value or if not obj_or_tag

I've always used the if not value method.

Thanks

Hi,

no, it is not necessary in a strict sense of the word. The instantiation of a BaseList2D (i.e. a tag, an object, a shader, etc.) can fail when your computer runs out of memory. In that case the symbol of the node will reference None. You handling this case or not only makes a difference in with what error message your program will stop (this hold true for all exception handling). But it is easier to debug code if you get a message that specially gives you a reason why the program did stop, rather than your code failing because an object (in the pythonic sense) is not what the code assumes it to be (e.g. Python would raise something like AttributeError: NoneType has no attribute InsertTag when the node instantiation did fail).

The practice to state something like if something is None: return makes sense if you design a function which specifically includes returning None in its signature. But it is often also used like shown here in your code, to irregularly stop a program when something is going wrong. While this usage is not specifically wrong, most style guides advise against it, because it makes it hard to understand why the program did stop and also that it did stop irregularly in the first place. Use exceptions and be verbose instead. So for your code this would be something like.

if obj is None:
    raise MemoryError("Could not instantiate object.")

Finally, if you say if not obj: or if obj is None: makes no real difference in this case (the literal None will evaluate as False and a node instance will evaluate as True). However, the first one is sometimes is considered to be bad style, because it lacks the verbosity and makes the code harder to read. It also might proof treacherous if you are not aware of the truth testing behaviour of the the Python object you are testing - for integer literals the value 0 evaluates as False for example.

Cheers,
zipit

Hi,

no, it is not necessary in a strict sense of the word. The instantiation of a BaseList2D (i.e. a tag, an object, a shader, etc.) can fail when your computer runs out of memory. In that case the symbol of the node will reference None. You handling this case or not only makes a difference in with what error message your program will stop (this hold true for all exception handling). But it is easier to debug code if you get a message that specially gives you a reason why the program did stop, rather than your code failing because an object (in the pythonic sense) is not what the code assumes it to be (e.g. Python would raise something like AttributeError: NoneType has no attribute InsertTag when the node instantiation did fail).

The practice to state something like if something is None: return makes sense if you design a function which specifically includes returning None in its signature. But it is often also used like shown here in your code, to irregularly stop a program when something is going wrong. While this usage is not specifically wrong, most style guides advise against it, because it makes it hard to understand why the program did stop and also that it did stop irregularly in the first place. Use exceptions and be verbose instead. So for your code this would be something like.

if obj is None:
    raise MemoryError("Could not instantiate object.")

Finally, if you say if not obj: or if obj is None: makes no real difference in this case (the literal None will evaluate as False and a node instance will evaluate as True). However, the first one is sometimes is considered to be bad style, because it lacks the verbosity and makes the code harder to read. It also might proof treacherous if you are not aware of the truth testing behaviour of the the Python object you are testing - for integer literals the value 0 evaluates as False for example.

Cheers,
zipit

@zipit Thank you much.