Hello D-people,

It is strange I didn't encounter debates regarding subject so far. That I mean is a way to distinct class members and globals from local identifiers. For example forcing to use 'this' to access member data and methods.

Then I first saw this approach in PHP (after C++ background), I was thinking that it is a stupidest idea - to type (and see) 'this->' allover again. But in time I get used to it and do really appreciate it. You see, benefits for a little more typing is code, much easier to follow. I find exploring foreign C/C++/D code is a bit pain because I always need to lookup and track identifiers - is it member or local or perhaps global, or even worse it might be hidden by local member... I bet you know the feeling.

Personally I avoid those pitfalls using (my own, sorry) naming contentions. So I have no problems with my own code, but what is my code compared to whole world =)

Good IDE able to highlight such information, say in tooltip, could help a lot. To bad we do not have one =(  And not always even if exist, good IDE available. For example looking at code on web page or paper.

It's a bit late for proposal, as such change will break too much existing code (although, fixing this would be not so hard for code maintainers), but I'd like to know your opinions on that matter.

thanks
-- 
serg.

Serg Kovrov wrote:
> Hello D-people,
> 
> It is strange I didn't encounter debates regarding subject so far. That I mean is a way to distinct class members and globals from local identifiers. For example forcing to use 'this' to access member data and methods.
> 
> Then I first saw this approach in PHP (after C++ background), I was thinking that it is a stupidest idea - to type (and see) 'this->' allover again. But in time I get used to it and do really appreciate it. 

It's obviously not enforced by the compiler, but I prefer a naming convention to distinguish class member data from other data.  Prefixing "this." to everything is relatively verbose, and the compiler still won't catch all bugs if you have a local variable with the same name as a class member variable (though I believe this is actually a "shadowing" error now).  In any case, the convention I use is:

class C
{
    int        m_val1;  // "m_" prefix for class members
    static int sm_val2; // "sm_" prefix for static members
}


Sean

On Tue, 05 Sep 2006 13:06:01 -0700, Sean Kelly <sean@f4.ca> wrote:

>It's obviously not enforced by the compiler, but I prefer a naming convention

Agreed. But I'm not so sure about...

>     static int sm_val2; // "sm_" prefix for static members

To me, the fact that it is a member is sufficient. Context tells me whether it's static, since my classnames have a 'c_' prefix.

l_Varname.m_Membername
  *Could* be a static, but much more likely an instance member.

c_Classname.m_Membername
  Must be a static member.

Actually, I'm amazed how quick and easy it has been replacing all the '::' and '->' operators with a simple dot. I'm being spoiled. I may have serious tantrums when I have to go back to C++ ;-)

Getting back to the point, I'm not particularly bothered by (for instance) the explicit 'self' in Python, but I don't see it as an advantage either. There are no major costs or benefits either way in my opinion.

The important thing is that a language shouldn't make breaking changes for the fun of it.

* Steve Horne:
> On Tue, 05 Sep 2006 13:06:01 -0700, Sean Kelly <sean@f4.ca> wrote:
> 
>> It's obviously not enforced by the compiler, but I prefer a naming convention
> 
> Agreed. But I'm not so sure about...
> 
>>     static int sm_val2; // "sm_" prefix for static members
> 
> To me, the fact that it is a member is sufficient. Context tells me
> whether it's static, since my classnames have a 'c_' prefix.
> 
> l_Varname.m_Membername
>   *Could* be a static, but much more likely an instance member.
> 
> c_Classname.m_Membername
>   Must be a static member.
> 
> Actually, I'm amazed how quick and easy it has been replacing all the
> '::' and '->' operators with a simple dot. I'm being spoiled. I may
> have serious tantrums when I have to go back to C++ ;-)
> 
> Getting back to the point, I'm not particularly bothered by (for
> instance) the explicit 'self' in Python, but I don't see it as an
> advantage either. There are no major costs or benefits either way in
> my opinion.
> 
> The important thing is that a language shouldn't make breaking changes
> for the fun of it.
> 

Of course, programmer who care could write:

ClassName
methodName(param_name)
StaticMethodName(param_name)
m_classMemberName or _classMemberName
sm_StaticMemberName or _StaticMemberName
locaVarName
package.FunctionName() or PKG.FunctionName() //shorter alias for package

If he cares about readability of his code by others it is perfectly fine. But it's a big 'if'.

You can imagine what mess could be if he doesn't...

But consider 'careless' code with forced 'scope prefixes' (sorry, i'm not sure how to call it):

this.do(param)
this.bar
classname.donow(param)
classname.foo
mywar
.thevar                //dot is global id
package.doit()         //forced fqn or alias

If you understand from this example (and i'm sure you are) what scope this identifiers belong to, you could see how this restrictions make much harder to foil a reader even on purpose.

--
serg.

On Wed, 06 Sep 2006 14:19:32 +0300, Serg Kovrov <kovrov@no.spam> wrote:

>If you understand from this example (and i'm sure you are) what scope this identifiers belong to, you could see how this restrictions make much harder to foil a reader even on purpose.

Readability is always, in the end, the responsibility of the programmer. There are always more ways to write unreadable code than to write readable code.

Despite all the style guides and the efforts to impose readability by authoritarian standards, there is no simple set of rules for what is or is not readable. Every style guide ever written can be ridiculed by simply finding the right example and working to rule.

Readability is inherently subjective, by which I mean context sensitive much more than I mean a matter of personal judgement. Many different factors affect the readability of any single piece of code, and some of those factors will always be in conflict.

For instance, a more explicit style can certainly make code clearer. But it can also make code more cluttered, obscuring what is important by burying it under tonnes of trivial details. This is why high level languages were invented in the first place.

And so programming language designers have to make choices - what should be explicit and what should be implicit, what should be enforced and what should not. Sometimes there are overwhelming reasons for going one way or the other. And sometimes, it really comes down to subjectivity, in the sense of personal taste.

That's why I'm sticking to my guns. There's nothing wrong with your opinion, and it works well enough in those languages where it is used, but it isn't any kind of absolute. And I want my existing code to still work tomorrow, whatever language it is written in.

-- 
Remove 'wants' and 'nospam' from e-mail.