How to determine code quality in PHP

[Etnu]

Such as?

OOP - particularly OOP combined with testing - is a much more powerful way to work. I can understand if it looks over-complicated or unecessary on first contact (I thought that when I was starting out) but statements such as above can be very misleading for people who are trying to learn. You don't have to, of course. Php is a bus you can hop on and off anywhere you like. But if you do want to learn to produce the best quality code you possibly can, OOP and testing is the way to go. We'd be selling people short to pretend that procedural is just as good or that it's all just a matter of personal preference.

Examples of awful places to use objects / classes:

- Templates themselves (a "templating" class is usually a good idea, but templates should be pretty much just plain text with some conditional logic thrown in).

- Entry points / boot strapping

- Maintenance scripts


The primary advantages of classes are:

- Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)

- Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).

- Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)

- Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).

That being said, using classes within php generally gives you some advantages, but they aren't the traditional variety:

- Using classes as "namespaces"
- Taking advantage of autoload / class_exists / method_exists / interfaces for some truly dynamic programming.
- Ability to override behavior of many engine internals using SPL.

And, of course, exceptions are tremendously useful, but there's no real reason why an exception has to have anything to do with objects.

Most of the traditional advantages afforded by classes are beneficial in the nasty world of strong, statically typed, compiled languages, but have little impact on the paradigm under which PHP shines.

Well, you can't deny that a code is definatly of better quality if it uses one class to handle let's say all the news functions instead of retyping all of the code everytime you need to do something with news.

Only an extremely novice programmer would do that. Classes don't magically create "reusability". You can get just as much reusability out of a collection of functions as you can out of a class. Do you write an entire regex engine every time you want to do some complex pattern matching on a string? Of course not, you use the (procedural) PCRE functions.

The problem with java in this regard is that primitives aren't objects; if they were, all that functionality could simply be replaced with method calls to number objects, as they are in Ruby. So really, this is a case of the language not being OO enough.

You mean half-assed? There's no real difference between doing 5.sqrt() and sqrt(5), if you look at Math as a namespace (think C++, where you might see something like std::sqrt(5)).

Wrapping functions in a class is useful in PHP because there isn't a namespace, but wrapping the native functions that you're never likely to alter in a class just for the sake of being "more OOP" is a waste of your time. I can say with a fair degree of certainty that you're not going to be re-implementing functions like sqrt, pow, and other basic math routines any time soon.

There's nothing wrong with mixing procedural and OO code. Think about ordinary human language -- some times you say something with the noun first, then the verb, and other times you do the reverse.

dog.poop() makes sense, but

walk(dog) does too.

poop.dog() and dog.walk() aren't things I think anyone is interested in seeing.

yes you can program everything in procedural (but u can also do the same thing in assembly, (or even binary)) but it just gets rediculos!

Yeah, ridiculous, like the Linux Kernel, most (if not all) BSD Kernels, Apache, PHP, most unix tools...

OOP doesn't really make development go any faster or make it any easier to maintain. In many cases (such as C++, which is usually just more trouble than it's worth unless you stick to the basic features), it actually slows development down.

or if you have a fetish for brackets you can program in SCHEME, same thing the program will work but ittl be a waste of your time

If it weren't for the crappy syntax, I'd love to use SCHEME (or lisp) more regularly. Unfortunately about the closest I get to those on a daily basis is javascript (which is basically lisp in C's clothing). Not sure what this has to do with anything, as OOP has nothing to do with functional vs structured programming anyway. Javascript is an OO ("everything is an object"), functional language.

write a multithreaded server and graphical browser in Java then write the same in procedural C and then youll see for yourself

You really have no idea what you're talking about, do you? OOP vs procedural has nothing to do with this. The only real advantage that OOP gives you with regards to threads is that it allows you for convenient storage of your mutexes and the like, but threads are usually a bad idea for most servers anyway (unless you're stuck developing for windows, which managed to completely drop the ball with regards to their process handling and relies on kludges like packing a bunch of individual services into a single process...so much for virtual memory as a safety mechanism!)

except for php5 which as language is quite nice and fast but lacks thousands of packages and classes that make Java and .NET languages so usefull for programmers

I'm pretty sure that the thousands of packages available through PECL and PEAR compare pretty favorably to what's available to Java and .NET programmers...and considering that PHP is the most popular web development language in existence I think it's fair to say that the programmers are getting by quite well with the tools that they have. Nobody's dropping PHP to jump to Java or .NET. They might be jumping to Ruby or one of the recent Python implementations, but anyone who does heavy web development realized long ago that the "P" languages (and those like them) are an infinitely superior tool for this type of task.

You have missed the key feature of OO...
PHP Code:
$table = new WithCrossLinks(new TableDisplay(new DefaultAccount()));

$table = withCrossLinks(tableDisplay(getDefaultAccount());
doSomethingWith($table);

Changing the noun-verb relationship has very little real impact on project development.

OO vs procedural code usually boils down to...

$obj = new Object();
$obj->doFirstThing();
$obj->doSecondThing();
$obj->doOtherThingWith(new Thing()); 

vs

$obj = Object();
doFirstThing($obj);
doSecondThing($obj);
doOtherThingWith($obj,Thing()); 

I suppose this distinction can help some people, but I haven't really found that it makes a single drop of difference on projects. I'm currently working on an absolutely enormous real time communication system that's almost entirely in C++, and the code that has been written so far is just as bad as the old system which was done in C.

A lot of the OO stuff doesn't work so well in dynamically typed languages for other reasons; for example, most languages have all kinds of funky ways of creating containers. In php you pretty much always just use a map (what they call "array"). You never think about iterators or insertion operators or any of that. It's just not a problem that has to be solved.

The biggest failing of OOP is that it attempts to solve the problem of "large" systems, when in truth large systems should simply be avoided like the plague. You should break up large systems into small, modular, and INDEPENDENT chunks, ideally with each one operating in separate environments. For large scale systems, this is a must anyway, since scalability pretty much mandates that every component of the system operate on a separate piece of hardware. In this model, OOP vs procedural is meaningless.

Yes, as long as they address problems in PHP, not some other language

That hits the nail right on the head. I'm still baffled as to why people try to implement patterns that have no place in PHP in PHP. It's just a waste of time.

[kyberfabrikken]

but php's file-scoped nature means

There's no file-scope in php ? Or did you mean global scope ?

Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)

Inheritance is a very powerful tool for reusability. Procedural lumps of code just can't do that.

dog.poop() makes sense, but

walk(dog) does too.

poop.dog() and dog.walk() aren't things I think anyone is interested in seeing.

Do you mean person.walk(dog) ? Or does the dog actually walk by itself, in which case dog.walk() would make sense ?

OO vs procedural code usually boils down to...

Not really. You are assuming a procecural mindset, which of course will lead to similar code in the to syntaxes.

In the example, you gave (the second), there is a static coupling between the utilizing code and the function Thing(). In the first example (which uses OOP syntax), you could pass the object in, and thus decouple that relationship.

[McGruff]

using classes within php generally gives you some advantages, but they aren't the traditional variety

Polymorphism? Really, that's the beginning and end of the OOP v procedural debate right there. Procedural got hit below the waterline in one of the very first exchanges and is sinking fast.

I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.

[Fenrir2]

I think it is easier to get design right with object oriented style. You have high level objects, which operate on lower level objects, which in turn operate on even lower level objects. You can spin this both ways, see?

No, this isn't true. If you have an object, this object handles all operations himself (if you've done OOP "right"). So that would be both lower and higher level operations.

The primary advantages of classes are:

- Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)

"Modularity - A quality of a system where it consists of various parts which separate cleanly and fit together well. High modularity costs some design time but pays back well through clarity, elegance, maintainability and flexibility."

I think you have better modularity (on a small scale) if you use functions because every function is essentially a module, "which separates cleanly". With OOP, an entire class is a module, and the functions depend on each other's effects, so a *class* is a module. I don't know if this makes a huge difference on this small level, but it could.

- Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).

You hide implementation with encapsulation. There is no difference here, because you hide implementation in methods or functions. You still hide the implementation in the same way.

- Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)

I assume we're talking about intra-application-re-usability, and not inter-application. Practically the only thing you can share between applications is a database class/are database functions.

As you said, you can easily reuse the same function or class. I think that functions are more reusable, because you could be able to reuse one (or two) methods of a class for a new one. You can't do that (unless you inherit from the existing class, which is a problem if you want to inherit from another class too), but with functions, you can easily reuse one function for different things. I don't think there is much difference here if you have multiple inheritance or something like mix-ins, but PHP doesn't have these.

- Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).

I don't think that there is a difference here, besides that the name of the class is explicit if you define it. You could easily add a comment like:

# these functions work on #{kind-of-thing}

But there is a problem here. In OOP, methods belong to an object, but if you use functions, they don't necessarily belong to the first argument of the function.

Example:

function add_to_todo($todo_list, $item){}

Does this function belong to the todolist or to the item?

And if we'd written it like this:

function add_to_todo($item, $todo_list){}

(I don't like the order of the arguments in this function personally)

If you use a class, that function would probably be in the TodoList class. If I'm uncertain about the order of arguments I want a function to have, I ask myself in which class I would put it if I were using OOP, and use that as the first argument ;-). So maybe some things are easier to get "right" if you use OOP.

Not really. You are assuming a procedural mind set, which of course will lead to similar code in the to syntaxes.

The syntax really doesn't matter. CLOS (yea, that's a thing in a paren language) uses this syntax:

(method object arg1 arg2 .. argn)

instead of:

$object->method($arg1, $arg2, .. $argn)

In the example, you gave (the second), there is a static coupling between the utilizing code and the function Thing(). In the first example (which uses OOP syntax), you could pass the object in, and thus decouple that relationship.

That's because you can't dispatch functions on arguments in PHP. With OOP, you can at least dispatch on one argument (the first). If you have a good type system, you can dispatch on all arguments (which means polymorphism on all arguments). But you're right, this is one advantage of OOP in languages without a good type system.

I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.

So, what is the benefit, besides having to hunt down the objects?

[Ezku]

No, this isn't true. If you have an object, this object handles all operations himself (if you've done OOP "right"). So that would be both lower and higher level operations.

Really? Ever heard of, say, a Facade?

Aren't you the least bit worried about not being able to create your own data types? With the way you're going, you'll need to emulate them with in-built structures on the spot, and have to handle them using special functions instead of them being neatly wrapped and contained. I have a hard time imagining encapsulation in procedural form. That's just in my head, of course, but it might be an indication of which approach would be easier to handle.

Some pseudo:

def output(data):
   switch(true):
      case is_string(data): print data; break;
      case is_int(data): print i_to_s(data); break;
      case is_float(data): print f_to_s(data); break;
      case is_array(data):
         foreach key => value in data:
            output(key)
            print " => "
            output(value)
            print "\r\n"
         end
      break
   end
end

# vs.

def output(data):
   print data.to_s
end

What happens when you have a format that needs to be handled differently? How do you solve it in the former case? By passing around handlers for different situations with the associated data? If so, why not just couple the two together to begin with? Tell me about your approach.

[CapitalWebHost]

I'm just amazed that my little comment in another thread was the catalyst for such a great discussion.

[Fenrir2]

Really? Ever heard of, say, a Facade?

Yes. A facade is something that wraps a hard to use interface in a nice to use class. But I think you missed my point. A facade doesn't solve the problem I mentioned, because it only makes things easier for the caller. What I meant is that with OOP, an object should handle all operations on the object (encapsulation). Some operations could be low level, others will be high level. They all belong in the same class. This way, you don't structure your code in nice modular blocks which accomplish the one task.

Aren't you the least bit worried about not being able to create your own data types? With the way you're going, you'll need to emulate them with in-built structures on the spot, and have to handle them using special functions instead of them being neatly wrapped and contained. I have a hard time imagining encapsulation in procedural form. That's just in my head, of course, but it might be an indication of which approach would be easier to handle.

This has nothing to do with OO ;-). You can create new datatypes transparently by building them from things that already exist. It just isn't explicit, so that might be why you haven't noticed.

The example code you give is ridiculous. The functional equivalent would be:

def output(data)
   print to_s(data)
end

(do you program in Ruby too? Your code is nearly correct Ruby code)

The ability to dispatch on types has nothing to do with OOP:

Instead of doing:

class Integer
  def to_s
    # do something
  end
end

class String
  def to_s
    self
  end
end

You do:

def to_s(Integer i)
  # do something
end

def to_s(String s)
  s
end

Unfortunately this is not possible in PHP. You got me, that's one + for OOP.

[kyberfabrikken]

Unfortunately this is not possible in PHP. You got me, that's one + for OOP.

Or in any other language for the matter, unless of course the datatype is explicitly declared ...

[Fenrir2]

Of course, it's like defining a class. (but you'd have multiple dispatch).

Bah, I think I have to create my own language.

[Ezku]

A facade is something that wraps a hard to use interface in a nice to use class.

You're thinking of Adapter, I believe. Facade is intended to wrap several subsystems into one.

What I meant is that with OOP, an object should handle all operations on the object (encapsulation). Some operations could be low level, others will be high level. They all belong in the same class.

If the Facade didn't do the trick, let me put it this way: have you heard of delegating? All the code related to completing an action doesn't need to be included in a single class (just as it doesn't need to be included in a single function!), they can be spread out to layers of delegates that handle increasingly lower level operations the deeper you go.

The ability to dispatch on types has nothing to do with OOP

I posit that without OO you cannot define your own types, which renders the following invalid:

The functional equivalent would be:

def output(data)
   print to_s(data)
end

You do:

def to_s(Integer i)
  # do something
end
def to_s(String s)
  s
end

This, of course, won't work at all if

• the language of choice doesn't support defining the same function multiple times with different arguments (or overriding the function with an ability to call the overrided one from the inside, in effect creating a CoR), or
• to_s() receives something that on top looks like, say, an array, but you'd like it to be formatted differently - you can't differentiate your "types" from the base ones

Either way, you're stuck at not being able to extend the functionality in question.

Am I making sense?

(do you program in Ruby too? Your code is nearly correct Ruby code)

Somewhat familiar with it. I just needed to try and remove the OOness of Ruby to construct a sensible example.

[beetle]

Are you guys are talking about function overloading being somewhat analgous to two classes that share a common interface? (or even implement an Interface proper?)

[Ryan Wray]

Are you guys are talking about function overloading being somewhat analgous to two classes that share a common interface? (or even implement an Interface proper?)

I do believe that is what Fenrir2 is trying to apply, yes.

[Etnu]

Polymorphism? Really, that's the beginning and end of the OOP v procedural debate right there. Procedural got hit below the waterline in one of the very first exchanges and is sinking fast.

Polymorphism is a crutch for statically typed languages. Dynamically typed languages need polymorphism about as much as a fish needs dirt. If polymorphism is the "beginning and the end" of OOP, then OOP is truly pointless. However, it isn't, as there are other OOP features that can be very useful.

I agree with some of the things you've said but I also think that OOP is not just for large systems. Any non-trivial piece of code will benefit from OOP. You will find different roles - ie objects - if you hunt them down.

It's not just for large systems, it's just foolhardy to say that OOP = quality code. It has nothing to do with it. If you read the end of my post you'll note that I point out that "large" systems are inherently flawed anyway.

[kyberfabrikken]

Polymorphism is a crutch for statically typed languages. Dynamically typed languages need polymorphism about as much as a fish needs dirt.

That is not true. Maybe you're confusing polymorphism with typecasting ?

[sweatje]

Polymorphism is a crutch for statically typed languages.

I would say catagorically untrue. Polymorphism is just as powerful in a dynamic language as a staticly typed one. Can you explain yourself further?

[Luke Redpath]

I have to echo the above sentiments - I'm not sure where you get the idea that polymorphism isn't useful in dynamic languages - polymorphism is just as useful in either static and dynamic languages even though implementation for one isn't neccesarily appropriate for the other (interfaces and typehinting in static languages vs duck typing in dynamic languages).

[stereofrog]

Of course, it's like defining a class. (but you'd have multiple dispatch).

Bah, I think I have to create my own language.

Before you begin take a look at the multi class:

multi(:foo, Integer) { |x|
	puts "integer #{x}"
}
multi(:foo, String) { |x|
	puts "string #{x}"
}

foo 10
foo "hello"

Quite nifty, isn't it?

[Fenrir2]

I think that polymorphism is important, even in dynamically typed language (but maybe less important). For example, Ruby's method === is based on it, and because Ruby has polymorphism, functions like Enumerable#grep() (wich uses ===) can be made.

Quite nifty, isn't it?

It certainly is! That looks a lot cleaner than a switch-dispatch in foo(). Thanks!

[pergesu]

I would say catagorically untrue. Polymorphism is just as powerful in a dynamic language as a staticly typed one. Can you explain yourself further?

I'm not entirely sure what he means, but my best guess is that duck-typing renders polymorphism irrelevant.

Before I show any examples, I want to point out that Ruby is the only dynamic language I know. I imagine other dynamic languages support duck-typing as well, but I'm not positive.

In Java, you could have the following code:

class Animal {
  public String talk() { return ""; }
}

class Dog extends Animal {
  public String talk() { return "woof"; }
}

class Cat extends Animal {
  public String talk() { return "meow"; }
}

// Some random method
public void speak(Animal a) {
  System.out.println(a.talk());
}

speak(new Dog());   #  woof
speak(new Cat());    #  meow

For something like that you'd probably use an interface instead, but you get the idea.

In Ruby, there's no need to create a base class or an interface. You just make sure that the class supports the #talk method.

class Dog
  def talk; "woof"; end
end

class Cat
  def talk; "meow"; end
end

def speak(a)
  puts a.talk
end

speak Dog.new  # woof
speak Cat.new   # meow

Polymorphism is a tool to write flexible, dynamic code in a statically typed language (though still not as flexible as a dynamic language). Ruby doesn't benefit from it, simply because it doesn't check types at compile time.

[kyberfabrikken]

I imagine other dynamic languages support duck-typing as well, but I'm not positive.

Yeah, that's a tautology - all dynamic languages support duck typing.

Polymorphism is a tool to write flexible, dynamic code in a statically typed language (though still not as flexible as a dynamic language). Ruby doesn't benefit from it, simply because it doesn't check types at compile time.

It's nitpicking I know, but you're getting it wrong. If you replace the word polymorphism with typecasting, your quote makes sense. The example you showed above, utilizes polymorphism. This is true for the java as well as the ruby example.

Off Topic:

... doesn't check types at compile time.

Does ruby code compile ? I thought it was interpreted ?

[pergesu]

The example you showed above, utilizes polymorphism. This is true for the java as well as the ruby example.

You're absolutely right. That Ruby code is polymorphic, even though the classes aren't related at all.

So that leaves me wondering what Etnu was talking about I just took my best shot...and missed

Off Topic:

Does ruby code compile ? I thought it was interpreted ?

Yeah, it's interpreted. It doesn't check types at compile time because there is no compile time.

[DerelictMan]

I'm not entirely sure what he means, but my best guess is that duck-typing renders polymorphism irrelevant.[...]

In Java, you could have the following code:
[...]

In Ruby, there's no need to create a base class or an interface. You just make sure that the class supports the #talk method.

class Dog
  def talk; "woof"; end
end

class Cat
  def talk; "meow"; end
end

def speak(a)
  puts a.talk
end

speak Dog.new  # woof
speak Cat.new   # meow

Polymorphism is a tool to write flexible, dynamic code in a statically typed language (though still not as flexible as a dynamic language). Ruby doesn't benefit from it, simply because it doesn't check types at compile time.

It seems you are confused as to what the term "polymorphism" actually means. Polymorphism, in the most generic sense, means that code can call some identifiable interface, and the runtime can dispatch that call to different implementations based on some characteristic. Polymorphism as it is being used in this thread is referring to the ability to dispatch to different method implementations based on the type of the object in question. It really doesn't have anything to do with dynamic typing or static typing.

Your Ruby example above is actually a perfect illustration of polymorphism. How does ruby determine what code to run when your speak() function calls a.talk? It determines this based on the way your a object responds to the "talk" message. Dog's implementation differs from Cat's implementation, but the speak() function doesn't need to know or worry about that. As long as the parameter can respond to the "talk" message (in some way, even if it ends up using a missing method handler) everything is fine. This is polymorphism...

[lastcraft]

Hi.

Enough point scoring already . What makes good code?

yours, Marcus

[kyberfabrikken]

What makes good code?

Why, I do ... Oh ... no more cheap points, you said ?

I suppose that we can keep enumerating technicalities, which are good practice, but doesn't ensure anything in and by itself. The real answer isn't a technical one though - it's the same as to "What makes a good novel". Good code has good litterary qualities.

As a programmer I often feel a bit misunderstood by my non-computer friends (I have a few left, yes). The general assumption is that programming is an engineering discipline - we all know the metaphore of 1's and 0's. Of course to some extend it is, but I have always felt that programming is much more of a linguistic discipline than a technical one. I failed math horribly in highschool, yet I make a good programmer (should I say it myself at least).

[Fjoggen]

Good code is like the perfect woman.
Hard to define, but it is love at first "site"