How to determine code quality in PHP

[lastcraft]

Hi...

I am also an ex-Hungarian user. A lot of the disadvantages have already been mentioned, but for me the extra clutter and endless, boring, dull, so terribly dull, typing just drove me away. Nothing is worth that much pain.

yours, Marcus

[tjyobazee]

I too was a Hungarian user. Although I just forgot about typing the datatype. I just went along typing a name of the varibale that makes sense to me.
People in my company use them tho. But I believe they are switching to a better naming method.

[kyberfabrikken]

oh ... welcome to hungarian anonymous ...

[tjyobazee]

oh ... welcome to hungarian anonymous ...

haha, where's the therapist? ^^

[sweatje]

The first step towards a cure is admitting that you have a problem.

[Ryan Wray]

The only place I can see hungarian being useful is when poorly named variables are employed and in spagetti code. That way you can't track down where the variables originate from (and hence how they are declared and initialised) and the name makes no sense. Well designed applications should make the application path (and it inputs) clear or atleast easy to find out.

[nacho]

I still use prefixes on ocassions, but I never use it to indicate the type, as PHP is loosely typed and, like Jason well said, it just does not make sense. I find useful though to indicate the scope of the variable:

// May there be any globals in the game
$gGlobalVar = 'I am evil';

// Arguments in functions/class methods
// I find useful to distinct an argument of a function variable
function ShowScope($aFirstArgument, $aSecondArgument){
    $var_inside_function = 'My scope is only this function';
}

// And class variables
class MyScope{

    private $mClassVariable;
} 

[Etnu]

Using classes says absolutely nothing about the quality of any given piece of code. It just tells you that the developers like to use the OO paradigm. Drupal is an excellent piece of PHP code, and it's totally procedural. mysql++ (was) an OO oriented version of the excellent mysql client libraries (for C), and it was a festering pile of crap.

In many instances in PHP, making classes on something doesn't make sense. I personally keep every function I write inside a class (even if it's just a static function, because it lets me take advantage of __autoloading and using class_exists and the like). However, there's just as much code that belongs at the file scope level as belongs at the class level. Assuming you're using MVC (or some other 3 tiered approach), usually M = classes, V = template files, and c (little c...) = some combination thereof.

A lot of people on this site focus on writing apps that are intended to stand on their own (usually on some hosted service), so their perspectives are going to be different from someone who spends their time creating web applications where they have total control over the machine they're running.

Prefixing member variables is truly pointless because you always have to access member variables through $this->. They make sense in C++ or other languages where you don't have to explicitly access the this pointer, but they make no sense in PHP. There's absolutely no ambiguity here:

if($this->someVar)

doing:

if($this->mSomeVar)

doesn't tell you anything.

Globals should usually just be avoided, and it's much simpler to just access them as $GLOBALS['whatever'] anyway.

The only thing that needs to be well commented is the interface (e.g. function / class / file headers). The only other comments should appear in complex code that requires explanation. You don't need to tell me that you're iterating over something. I know what a for loop is. Write your comments for programmers, not for students. When you write comments, do it in such a way a to be easily picked up by doxygen / phpDoc and make everyone's lives easier.

Don't mix programming styles in user land code. Make your code predictable. If you use exception handling extensively, don't suddenly decide to have nested error checking in one place (unless you have a really good reason). Stick with the same casing / underscores (php forces you to use underscores, but I say it's ok to ignore php's convention here and stick with one that you prefer).

Do not use databases. . Well, I see, most of the developers, are to disagree. So let's periphrase it. Use databases, only for projects where data is very sensitive, changes fast, regularly, and is large. So what is large? It's a relative idea. One may say 12 MB, 700 MB or 4 GB. According to my experience 99% of all the projects don't need (MySQL,Acess - like)databases. "Please, excuse us but the MySQL server is not working a the moment", "The maximum connections exceed the limitations of the MySQL server", etc.

Nonsense. For most tasks that people fiddle around with creating flat files, in memory storage, or some other stupid mechanism, you're going to be better off using a database. I have to assume that your experience is very limited if you make that "99%" claim.

Code should be testable in the simplest way possible. I should be able to write a script that calls your classes / functions and have very simple conditions to test for. If I call $Template->render(), I should expect to see template output.

Lastly -- don't assume that what's good for the goose is good for the gander. PHP is NOT java, it's NOT C, it's NOT C++, it's NOT Ruby, Python, Perl, or any of these things.

What is good practice in PHP can be horrible practice elsewhere, and vice versa. If I had a dollar for every time I heard some first year graduate telling me some GoF brainwashed crap while failing to actually solve the original problem in a reasonable time frame, I'd have at least $20 so far this year.

[nacho]

Prefixing member variables is truly pointless because you always have to access member variables through $this->. They make sense in C++ or other languages where you don't have to explicitly access the this pointer, but they make no sense in PHP. There's absolutely no ambiguity here:

if($this->someVar)

doing:

if($this->mSomeVar)

doesn't tell you anything.

Ouch

Very good point! Thanks for pointing it out.

Never thought about it actually, how stupid that might sound. (I guess $this-> becomes invisible somehow ...). I'll be reconsidering ...

[McGruff]

In many instances in PHP, making classes on something doesn't make sense.

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.

[Buddha443556]

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.

Takes experience with both to know when to use either of them. I wouldn't want to discourage people from gaining such experience nor do I think any one here would.

... people who are trying to learn.

People who are trying to learn OOP or testing should read and follow your posts McGruff, even an old fart like me has learned more than a thing or two.

Back on topic:
I've used App Hungarian Notation in PHP never thought I need a 12-step program though. Sys Hungarian Notation has never made much sense to me though maybe I've just not found a use for it.

[Kokos]

Using classes says absolutely nothing about the quality of any given piece of code.

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.

[Ryan Wray]

Such as?

Such as in Java when you need to create a class to hold the program entry point (main). I personally find this unneccessary in most cases - though only an issue when writing it out by hand, instead of using an IDE to generate the stubs. I know we were being PHP specific, but that's an example of Java.

[McGruff]

I don't know anything about Java. What about php?

[Selkirk]

I was on a team where hungarian was the standard. I really loathed it. The focal point of my hate was a variable named cChar. Type based prefixes are the work of the devil. Scope based prefixes aren't too bad.

This is getting off topic, but I think that would be a nice language feature. $local, @member, @@global instead of $local, $this->member, $GLOBALS['global']. To bring it back on topic, I always use the $GLOBALS keyword when I use a global (less and less) rather than the global keyword. In my mind, globals should be combersome to use and to type and explicitly distinguished.

[Viflux]

I don't know anything about Java. What about php?

While I'm not prepared to argue the validity of using objects to the complete (or as near as possible with PHP) exclusion of procedural code, I will submit that the vast majority of object-oriented code in the PHP universe is object-oriented simply for the sake of being object-oriented.

An example posted earlier in the thread that inspired this one demonstrates that very well.

PHP was developed as a scripting language. While the object-oriented capabilities are certainly a blessing to programmers of advanced or extensible systems, there are certainly instances where using them is definitely not desirable. Another example would be a script I've created to aid in the creation and deployment of new projects. It's interactive via the CLI, and perfectly suited to procedural code. Of course, such a project would be better handled by a shell script, but as a Windows user I find PHP more friendly than the alternatives.

[McGruff]

Sure: for something trivially simple there might not be any need for OOP. As soon as the number of lines of code gets into three figures or thereabouts I'd expect to start finding objects though.

[it_pimpin]

i agree with your statements

[DerelictMan]

Off Topic:

Such as in Java when you need to create a class to hold the program entry point (main). I personally find this unneccessary in most cases - though only an issue when writing it out by hand, instead of using an IDE to generate the stubs.

Agreed, without an IDE it is definitely a pain to type "public static void main(String[] args)" just for a simple program (but then again, who uses Java for simple programs?), however I think it is a side effect of Java's namespace/package system. It means even your application's top level code is nicely tucked away in it's own little spot in the namespace, so in the future if you ever need to reference it you can call com.example.someapp.SomeApp.main(args). I know that you would very rarely have a need to call a main method that way, but I like the fact that it is practically impossible to ever have any namespace headache/conflicts when integrating any two pieces of Java code, even if the code wasn't designed to be integrated. (This is, of course, assuming the program wasn't put in the default package.) My number one complaint about PHP is the lack of namespace support so if I have to occasionally type "public static void main(String[] args)" to get it, I'm fine with that.

Sorry for the OT...

[Ryan Wray]

I don't know anything about Java. What about php?

Well, I'm using Java here as an example but I can transfer it over to PHP. Look at Java's Math class: http://java.sun.com/j2se/1.4.2/docs/...lang/Math.html.

Now, is simple full of static methods. Of course, many probably would just classify this as procedual code wrapped in a class (an construct used in OOP). The class should be taken away. Just a bunch of procedual functions I think makes more sense, I can't think of a better OO way.

[sweatje]

Sure: for something trivially simple there might not be any need for OOP. As soon as the number of lines of code gets into three figures or thereabouts I'd expect to start finding objects though.

I would say Hello World is not a good candidate for OOP or Design Patterns

[33degrees]

Well, I'm using Java here as an example but I can transfer it over to PHP. Look at Java's Math class: http://java.sun.com/j2se/1.4.2/docs/...lang/Math.html.

Now, is simple full of static methods. Of course, many probably would just classify this as procedual code wrapped in a class (an construct used in OOP). The class should be taken away. Just a bunch of procedual functions I think makes more sense, I can't think of a better OO way.

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.

[McGruff]

Look at Java's Math class

I guess we're spoiled in php with a multitude of ready made functions with which to build our classes (or not..).

I do occasionally find some poor orphaned fns like that which end up in a class purely for somewhere to put them. I always have nagging feeling that they ought to have a proper home somewhere though. Should the math fns become part of a Calculator class?

[McGruff]

I would say Hello World is not a good candidate for OOP or Design Patterns

Which raises an interesting question what is good OOP? Although I'd say TDD is a best practice it doesn't always produce a perfect design - just something good enough to pass the tests. "Perfection" is always a refactoring away, somewhere in the distance. I guess over time more permanent parts of the code will become polished and honed. The emphasis on do-the-simplest-thing-to-pass-the-test ought to help avoid Hello World monsters.

[Ryan Wray]

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.

Could you expand further. I thought in Ruby it was the same situation, with a Math module being defined. The main difference being you can include this module:

include Math
sqrt(144)

This makes the code practically procedual. A Modules like Math is really just a class with static methods under a different name in my eyes. Fortunetly in Ruby modules make great sense with mixins which offers some great opportunities.

Should the math fns become part of a Calculator class?

I don't personally think so. Objects make sense for most things because it allows us to abstract away from the raw computer nitty-gritty and stop thinking like a computer but a person; it makes it more 'real life'. However, somethings - like standard mathematical operations - would make less sense if they were further abstracted. They are already common knowledge and make sense as they are.

When you say Calculator class, do you mean one that is to instanated in someway? I just can't envision a clean solution.