[Tutor] Efficiency of Doxygen on Python vs C++?

[Kent Johnson]

Stephen McInerney wrote:
> Kent,
> 
>>> I was asking if it's a recognized good programming practice to
>>> declare and initialize *all* members in the class defn.
>>
>> What do you mean by "initialize *all* members in the class defn"?
> - obviously I meant to say do it in the __init__() method,
> I wrote the snippet as I was rushing out the door to an exam,
> but I think the intent was clear.

It was definitely not clear to me. Judging from his latest reply it 
doesn't seem to be clear to Alan either.

>> If you mean to initialize the variables in the __init__() method:
>> maybe this is more common but I don't think I have ever seen it 
>> recommended to initialize all variables in the __init__() method. 
>> Certainly there are times when it makes sense to have some of the 
>> initialization in other methods that are called from __init__().
> 
> I only said "make a token dummy assignment in __init__() to hint
> to the static analyzer the name and expected type, I didn't say
> "you must do all the actual initialization itself in __init__()".

So if an attribute is initialized in a different method would you still 
put a dummy initializer in __init__()?
> 
> In the context of the original question
> "where and how should we assign class members in order
> to flag member names and types to static analyzers like
> Doxygen or pylint?"
> I understood that people were agreeing
> "Yes, assigning each member token values in the __init__()
> method is a good practice".

I honestly don't see how you can conclude that. My post was the first 
one that mentioned __init__() at all. You have been talking about the 
class definition which could mean "anywhere in the scope of the class 
statement" or, as I thought you might mean, "anywhere in the scope of 
the class statement that is not in a method". I personally would never 
interpret "class definition" to mean the __init__() method.

I really am trying to understand what you are asking, it is not clear to 
me at all.

Kent