Page 1 of 1

open source code, best practices

Posted: Wed Nov 21, 2007 3:31 pm
by s.dot
I didn't really know what to name the title of this. I'm working on a software package that I plan to sourceforge.

1) It will be completely procedural, well almost, 1 class. Personally I don't see anything wrong with this. Procedural code is more straight to the point and has (arguably) less overhead. phpbb is completely procedural, although that may be to maintain their php3 compatibility (at least up to versions 2.x.x... haven't even downloaded any phpbb 3 rc's yet). "gurus" will argue oop till their death, so, if you see code that's obviously written for php5, do you frown upon it if it's not OOP?

The package I'm building has MVC design, sort of, just not implemented in an OO way.

2) I'm only writing this package for php5 >= 5.1.3.. I think. 5.1.something. That way I can make use of the hash() algorhythms, and deleting old session files with session_regenerate_id(). Considering this package won't be released until after the new year, support for php4 will be dropped and a lot of hosts will have 5 installed. Do you see this being a huge problem?

3)... I had more questions when I decided to make this topic.. I guess they got lost somewhere. =/

Posted: Wed Nov 21, 2007 4:08 pm
by veridicus
1) I'd rather see well written procedural code than poorly written OO code. You're the developer, so you decide what's best. Choose whichever method will best serve the project in the long term.

2) I don't see it being a huge problem, but I'm not sure exactly what percentage of hosting providers support PHP 5. Frankly, if someone is very interested in using your software they should push their provider to upgrade or switch providers. Only supporting PHP 4 these days is pretty lame for any hosting provider.

As for the specific version of PHP 5, I would take a look at what versions come with default installations of Red Hat, Debian, and CentOS. So many providers offer these by default that you can guess what version many of your users will have. You can also check the web sites of the largest providers to see what version they offer.

My primary concern is always the project itself. I would use whatever features / versions best serve the project. Everything else will follow naturally if people are interested.

Re: open source code, best practices

Posted: Wed Nov 21, 2007 6:18 pm
by alex.barylski
scottayy wrote:I didn't really know what to name the title of this. I'm working on a software package that I plan to sourceforge.

1) It will be completely procedural, well almost, 1 class. Personally I don't see anything wrong with this. Procedural code is more straight to the point and has (arguably) less overhead. phpbb is completely procedural, although that may be to maintain their php3 compatibility (at least up to versions 2.x.x... haven't even downloaded any phpbb 3 rc's yet). "gurus" will argue oop till their death, so, if you see code that's obviously written for php5, do you frown upon it if it's not OOP?

The package I'm building has MVC design, sort of, just not implemented in an OO way.

2) I'm only writing this package for php5 >= 5.1.3.. I think. 5.1.something. That way I can make use of the hash() algorhythms, and deleting old session files with session_regenerate_id(). Considering this package won't be released until after the new year, support for php4 will be dropped and a lot of hosts will have 5 installed. Do you see this being a huge problem?

3)... I had more questions when I decided to make this topic.. I guess they got lost somewhere. =/
1. Personally if I seen an application advertised as PHP5 - I would expect it to be done using classes and all the OO keywords that came along with it (private, final, interface, abstract, etc).

2. I'm not sure what hash functions you are refering too, however if your not going to take advantage of language constructs why not make it compatible with any version of PHP and implement or copy/borrow the hash functions from another library?

If you want to develop in procedural and you feel more comfortable in it, giver.

What I would argue is that, using procedural may not be a sign of inexperience (I know a few old-timer developers that have mentored me over the years who still write in plain C and Windows SDK) but rather that of stubborn-ness. :P

It's commonly argued by procedural proponents that you can effectively write *reusable* and *clean* designs as one might with OOP. Here is what you have to remember.

The fellow's that introduced OOP started in procedural and you know what they say: "Neccesity is the mother of all invention"

Obviously some procedural developers seen problems in writing code and devised some techniques to avoid/reduce those problems (data hiding, etc).

It's not like procedural developers started in OOP and worked "forward" into using globals. If you are having a hard time understanding your OOP code, it's likely because you are missing one or more concepts of OOD/OOA.

I am not trying to discourage you, infact perhaps it's best you stick with procedural for a while. Once you have the application hammered out, it may be easier recognize objects, etc. One common pitfall I see constantly in open source projects which use OOP is the over (zealous) use of classes. Not everything in an application (is or can) be represented by an object. For example, classes which output HTML drive me nutts. Thats better left to a template not an object.

p.s-What kind of application is this? When do we get to see it?

Cheers :)

Posted: Wed Nov 21, 2007 7:58 pm
by RobertGonzalez
My general feeling is that if it is an application of any significant size that it should be OOP. Whether PHP 5 or even some other language. Smaller apps/scripts that do not benefit from OOP are just as well procedural. Regardless of the style, all code should be clean, well commented and secure.

And for the record I am one of those OOP PHP 5 fanatics that will class something as soon as it gets to be more than one function if it feels right to do it that way. But there is still a place for procedural style coding, and in some circumstances, OOP code can be essentially procedural code wrapped in a class.

Posted: Thu Nov 22, 2007 1:22 am
by s.dot
No, regarding the oop vs. procedural thing, that's not really what I was asking. I was asking in general if procedurally written code would be frowned upon by you oop fanatics. Maybe some of you implied that with your answers.. I'm not sure.

@hockey, php5 isn't improved just for the object oriented area. hash() is a nice function which would eliminate my dependency on say, the sha256 library. I'm trying to do my whole thing from scratch.. reinventing an 18-wheeler worth of wheels while I'm at it. :P

Also, session_regenerate_id() allows you to delete the old session files with php5.. built into the function when you pass a boolean as an argument, which is something I've been looking for.

I'm sure there are a few other things as well. Oh yeah, stripos(), str_ireplace() too, just off of the top of my head.. gives you the ability to do functions without regex and the i pattern modifier.

Posted: Thu Nov 22, 2007 3:30 am
by Maugrim_The_Reaper
1) It will be completely procedural, well almost, 1 class. Personally I don't see anything wrong with this. Procedural code is more straight to the point and has (arguably) less overhead. phpbb is completely procedural, although that may be to maintain their php3 compatibility (at least up to versions 2.x.x... haven't even downloaded any phpbb 3 rc's yet). "gurus" will argue oop till their death, so, if you see code that's obviously written for php5, do you frown upon it if it's not OOP?
I'd more than likely frown ;). But not simply on the OO question. A bigger question is can I verify your library/app works? Will you have an automated testing suite? How easily can I modify your code? Is it well documented?

The main problem I have with procedural is that it's associated with a certain development approach - no testing, little documentation, no apidocs, and usually it's extremely difficult to modify it without unforeseen consequences elsewhere in the global mass of functions. If you practice procedural, and avoid those problems, then whether it's OO or not won't worry me. If it's procedural and I can't find good documentation or tests, then I'd find another library/app - I find procedural code without the structure of OO tends to be too difficult to read through. At least with a class you have some sort of API, and you know which classes are upfront, and others behind the scenes helpers.

Lastly, I know from a comment you made before you don't practice Unit Testing - do you use any form of automated testing? I suspect you might find something like PHPT a bit easier to get working with in a procedural setting. That's not catering to the non-tester either - I used PHPT myself for PHPSpec since it was easier than siding with a unit testing framework at the time.

Posted: Thu Nov 22, 2007 10:16 am
by Kieran Huggins
a mild :(

I would count that as a negative when comparing similar solutions, but it wouldn't preclude me from using it. As long as it's well written *and documented* it's not a huge deal.

Posted: Fri Nov 23, 2007 10:00 am
by superdezign
If it's not OO, chances are that if someone who's applications are OO wants to implement yours into theirs, they'd either end up wrapping it in a class anyway, or having to make some sort of special case to make use of it outside of their normal programming style. The reason OO became popular over the last few decades is because it allows us to think in more realistic terms and work at a higher level of abstraction.

I like OO because it makes development and maintenance easy for me as a programmer, and when I have a choice between a procedural app and an OO app, I tend to lean towards the OO one.