NYCPHP Meetup

[inforequest]

Jayesh Sheth jay_nyphp-at-fastmail.fm |nyphp dev/internal group use| wrote:

>Hello all,
>
>I was recently reading through the phpBB source code, and had some
>observations to shares. In most of the pages / script files I looked
>through, there were 1000 - 2000 lines of PHP code, with no functions or
>comments. While the code itself is strictly procedural, it is also to
>the point, and not indecipherable.
>
>Still, some interesting questions came to me: how can one of the most
>popular PHP applications be written in eighties-style procedural code?
>Or, to rephrase it: are object-oriented design, (fancy) frameworks not
>useful in practice? How many of you have worked with commercial, open
>source or in-house frameworks? Have you found these frameworks to be
>useful in the long run, or do they just get in the way?
>
>I have long been a fan of PEAR (and other external / third-party)
>libraries. I much prefer to save myself work, when I do not have to
>reinvent the wheel. Still, in many companies, people prefer to write
>everything from scratch, often wrapped up in laborious frameworks. In
>your collective experience, what's the best policy for code development?
>In other words: bang it out, test it, ship it, receive feedback, fix it,
>and then back to the beginning again, or: huge design upfront, OO or
>functionized code,UML diagrams, and the 'f' word: a framework.
>
>I personally cannot write strictly procedural code any more, and I
>prefer a mix of functionized and OO code. Still, real world applications
>- popular real world applications, often totally avoid this approach.
>So, what gives?
>
>- Jay
>_________________
>
Hi jay.

As someone who works with alot of other people's code, I used to always 
want to re-write stuff rather than learn-and-then-hack with it. It seemd 
like the best aproach in the long term, for everyon einvlved (client, 
maintainers, mission).

I was wrong.

There is alot of cognitive overhead to classes and frameworks. If you 
have to step into an app, you need to get to a point where you can 
visualize the framework before you can be sure of the consequences of 
changes, right? That's a big headache for a highly-utilized yet 
infrequently-modified system.

With procedural code, a new coder can step through it rather easily and 
be pretty sure of the consequences of change... the places where scope 
is ill-defined or dependencies exists pop out at you.

I know I am way out on the fringe when it comes to professional PHP 
coding, but I can understand when an older app with a large community 
sticks with an existing procedural code base. It makes alot of sense to 
me, given the circumstances. Of course, every situation will put its own 
weights on those factors.

-=john andrews
http://www.seo-fun.com