Very basic OOP feedback

[logic_earth]

We don't all have the benefit of scrolling. My scrolling is Page Up, Page Down, Arrow Up and Arrow Down. Scrolling becomes laborious with a file that contains a 1000+ lines, of code or other wise.

So you just randomly pick a variable you see and use it? Okay...

In any case i don't see how underscores help variables, inside or outside the object. You have to look at the declaration anyways to find them. And guess what, the visibility is right next to them wow. Unless you just randomly use variables you find laying around your code...

[Stormrider]

I don't subscribe to IDEs or WYSISWYG editors. I use, vim/vi or a plain text editor. Java offends me and I try to avoid using anything made in java as much as is permissible...

So, would you like all developers to abandon good programming habits simple because some tool can "autocomplete" and "and tell you what type it is"? You never program for yourself today. You program for yourself and everyone else tomorrow. Who's to say the day won't come when you or a co-worker, if you have one, won't have an IDE? How will you or that person function then?

We don't all have the benefit of scrolling. My scrolling is Page Up, Page Down, Arrow Up and Arrow Down. Scrolling becomes laborious with a file that contains a 1000+ lines, of code or other wise.

OK, well clearly, that is your call. You miss out on the benefits a decent IDE brings. And I don't know what WYSIWYG editors have to do with things, or why you are even comparing them to an IDE, I'd never use a WYSIWYG editor. The editor I use is just a plain text editor, with enhancements like syntax highlighting, autocomplete etc - which help prevent mistakes in your code, and can tell you immediately where you are going wrong.

[Stormrider]

Example: You're editing someone else's code and see $this->config. Their code is consistent with Zend coding standard--therefore you know this variable is public.

No, you are missing what I am saying.

I am talking about USING the varaibles, not SEEING them. If I see a variable in code, I can ctrl-click it, which takes me right to the declaration and I can see straight away what it is.

If I want to USE a variable when coding, how do I know whether to start with an underscore or not? I have a variable called 'config', but can't remember if it is private or public.. so what do I start typing? $this->_config or $this->config? You have to visit the declaration anyway to find out.

I could also litter my code with comments reminding me what was going on 2 pages ago, to save scrolling, I just prefer not to litter the code with reminders of things because I am too lazy to check, or don't use a good enough editor.

[bhanson]

No, you are missing what I am saying.

I am talking about USING the varaibles, not SEEING them. If I see a variable in code, I can ctrl-click it, which takes me right to the declaration and I can see straight away what it is.

If I want to USE a variable when coding, how do I know whether to start with an underscore or not? I have a variable called 'config', but can't remember if it is private or public.. so what do I start typing? $this->_config or $this->config? You have to visit the declaration anyway to find out.

I could also litter my code with comments reminding me what was going on 2 pages ago, to save scrolling, I just prefer not to litter the code with reminders of things because I am too lazy to check, or don't use a good enough editor.

Your argument doesn't make sense.

In order to use variables, you have to see variables. By seeing variables that prefix underscores you're getting free visibility hinting for virtually no cost, without having to "ctrl-click" on every one.

If you have a variable called '$config' then you know it is NOT private, that's the entire point, you don't have to visit the declaration to find out.

There's a big difference between "littering" your code with comments and prepending one character for applicable cases. Obviously I'm only for the use of the underscore because it is very non-intrusive. I would be adamantly against something like $public_variable, $protected_variable, $private_variable.

[Stormrider]

If you have a variable called '$config' then you know it is NOT private, that's the entire point, you don't have to visit the declaration to find out.

If you see a variable called $config being used from another class, then you already know it is not private, even if you don't use underscores for private variables! The fact that it is being used at all suggests you can use it again.

If you can't see the variable that is being used, then you have to visit the declaration anyway to find out whether it starts with an underscore or not.

Think about it.

[bhanson]

If you see a variable called $config being used from another class, then you already know it is not private, even if you don't use underscores for private variables!

I never said it did not, but that is not every case where it is useful.

If you can't see the variable that is being used, then you have to visit the declaration anyway to find out whether it starts with an underscore or not.

Duh, but if you can see the variable being used, then you get more information from it using underscores than not.

Example:

<?php

class LargeClass extends SomethingElse
{
    // Lots of properties

    // Lots of methods

    protected function fooToBar($foo)
    {
        $newFoo = $this->doSomething($foo);
        $this->baz = $newFoo;
        return $newFoo;
    }

    // More methods
}

You're working on method fooToBar().

Things you don't know:

• What is the visibility of $this->doSomething()?
• What is the visibility of $this->baz?

And this is compounded when you call fooToBar()

Alternative:

<?php

class LargeClass extends SomethingElse
{
    // Lots of properties
   
    // Lots of methods

    protected function _fooToBar($foo)
    {
        $newFoo = $this->_doSomething($foo);
        $this->_baz = $newFoo;
        return $newFoo;
    }

    // More methods
}

Now you know:

• $this->_doSomething() is now private/protected, it's only meant to be used internally
• $this->_baz is private/public

And now this information (instead of the lack of), is compounded to all other internal function calls.

Two extra, useful pieces of information that is gathered in passing for nearly no cost. How is that bad?

[Stormrider]

Yes, you get extra information, but what good is that information? I don't need to know whether something is private/public/protected, all I need to know is 'can I use it'. If it is being used, then clearly the answer is yes.

[imaginethis]

So you just randomly pick a variable you see and use it? Okay...

In any case i don't see how underscores help variables, inside or outside the object. You have to look at the declaration anyways to find them. And guess what, the visibility is right next to them wow. Unless you just randomly use variables you find laying around your code...

I'm not exactly sure how you like to read code, but I don't start at the top of some class and start reading. I trace through the path of executed processes. When reading the code that subscribes to similar standards, I don't have to go looking for a variable to know how I may or may not use it.

OK, well clearly, that is your call. You miss out on the benefits a decent IDE brings.

The decision was not so much a choice but an unfortunate side effect of my choice in operating systems. I looked for IDEs for linux and found none, then stopped being lazy.

And I don't know what WYSIWYG editors have to do with things, or why you are even comparing them to an IDE, I'd never use a WYSIWYG editor. The editor I use is just a plain text editor, with enhancements like syntax highlighting, autocomplete etc - which help prevent mistakes in your code, and can tell you immediately where you are going wrong.

WYSIWYG as in Dreamweaver which is widely used by windows users.

[bhanson]

Yes, you get extra information, but what good is that information? I don't need to know whether something is private/public/protected, all I need to know is 'can I use it'. If it is being used, then clearly the answer is yes.

It just helps you understand how the class works quicker and easier.

Whenever you enter a new project it takes time to be able to "wrap your head" around what they're actually doing. Being able to instantly identify the intent of method calls is pretty useful.

So yes, you see something and know, "you can use it."

You know you can use it within the scope of the document you're at. Using underscores you know what scope the function is intended to apply to.

Here's an analogy: You're driving on the freeway and see a sign that says, "Los Angeles - Next 3 Exits".

This is like using underscores, you know you can use the exits and you know there are three places you can use them.

Not using underscores would be like the sign saying, "Los Angeles - Exits Ahead".

"You can use it" but you don't know how far Los Angeles exits go.

If you don't take the first exit, will there be another one?

[imaginethis]

Yes, you get extra information, but what good is that information? I don't need to know whether something is private/public/protected, all I need to know is 'can I use it'. If it is being used, then clearly the answer is yes.

Your mistaken. There are times when knowing a member variables label is important.

class CanAccess
{
  private $_data = 'I can access this';
  public function  access()
  {
     echo $this->_data; // Works
  }
}

class CannotAccess extends CanAccess
{
  public function access()
  {
    echo $this->_data; // Fails
  }
} 

[Stormrider]

Right, and so how does having the underscore help there?

The underscore naming technique was to get around the fact that PHP 4 didn't have a concept of private variables. It's no longer relevant, and while there are some limited benefits, I'd rather keep my naming consistent.

[AnthonySterling]

The only real benefit I can see, is that you would know the property is not public.

This would still be too ambiguous for my liking I'm afraid...

[imaginethis]

Right, and so how does having the underscore help there?

The underscore naming technique was to get around the fact that PHP 4 didn't have a concept of private variables. It's no longer relevant, and while there are some limited benefits, I'd rather keep my naming consistent.

To each there own I suppose. I guess the only convention that matters is the one your paid to use.

[franko75]

Glad I mentioned the underscore....

As an aside, thanks to all for a) feedback on my crappy OOP-ish code and b) lively, informative discussion!

However, I am still unsure as to whether to use an underscore for private methods/variables - such has been the quality of both arguments!

[bhanson]

Glad I mentioned the underscore....

As an aside, thanks to all for a) feedback on my crappy OOP-ish code and b) lively, informative discussion!

However, I am still unsure as to whether to use an underscore for private methods/variables - such has been the quality of both arguments!

Use whatever the coding standard you're using says to do.

[franko75]

I'm going to go without the underscore, as it's in keeping with the framework i use (obviously not for my own rubbish example), whose coding standards i'm taking on board. I was just curious about whether or not it should be adhered to. Thanks to all