Re: [Phpgroupware-developers] Proposal execution speed vs. documentation and code maintenance

[Alex Borges]

El lun, 04-08-2003 a las 02:38, Dave Hall escribió:
> Alex Borges <address@hidden> wrote:
> 
> > I agree.....
> > 
> > Even an optimizer script for converting cvs to optimal (need to 
> > supportupdates, else the patches would get all messy or wed have to 
> > mantaindifferent, identical branches for each version), 
> 
> Then we would have a huge mess, look at what happens with getting AM
> snapshots into our CVS, and that does not even include comments removed
> (which could help with speed there).
I didnt explain myself (VERY LATE HERE).
Someone (Most definitivly not me) should make a script to optimize it,
call it deploy. This way we mantain and document (if such is the final
desition) as we do now, and whoever wants to do the optimization calls
the script. Then its the user's problem to have a copy of cvs or the
tarball, update it as needed, and call the deploy script when an update
has happened. One branch and thats it.

> 
> I think if performance is a real issue for a site, they should co from
> cvs strip the comments themselves, then test it, copy it into their
> production environment.
> 
> > that could 
> > also (this
> > is needed) optimize the templates, which almost never should have 
> > actualspaces (only nbsp, else, space is ignored by the browser).
> 
> This is pretty simple to do imho.  Just insert the new lines where
> needed to make to more readable.  There are tools for indenting html if
> you need to fix/edit a template, then where you are done just remove all
> tabs :)

I guess this is how it works now.

> 
> Cheers
> 
> Dave
> 
> > 
> > 
> > 
> > El lun, 04-08-2003 a las 00:53, Kai Hofmann escribi:
> > > I would like to discusse the problem of execution speed versus
> > > code maintenance/documentation here.
> > > 
> > > In the past you tried to optimize execution speed by using tabs 
> > instead of
> > > spaces for code formatting (see coding style guide), avoiding 
> > comments etc.
> > > On the other hand code should always be readable/maintainable,
> > > understandable
> > > and extendable. (for example I proposed to use phpDocumentor).
> > > 
> > > >From my point of view a documented and maintainable code is much 
> > more> important
> > > than execution speed, because execution speed can be reached by 
> > using> things like phpAccelerator which precompiles code 
> > automatically rmeoving
> > > comments and formatting.
> > > But I respect your point that a lot of people don't have the php
> > > installation under
> > > their control and so they can not use things like an accelerator.
> > > 
> > > So I would suggest another solution:
> > > 
> > > 1) keeping the source code in the cvs documented and maintanable
> > > 2) for release archives checkout the actual cvs and then strip 
> > comments,> spaces etc. from it.
> > >    (there are tools freely available to do this). 
> > >    This code is not maintainable any longer, but fast instead.
> > > 
> > > as a result you have documented, maintainable code for developers 
> > in the cvs
> > > (everyone who develops
> > > on phpgroupware is able to install a phpaccelerator on its own 
> > developing> machine).
> > > On the other hand you have fast code without comments etc. for 
> > productive> usage.
> > > 
> > > Greetings
> > > 
> > >    Kai
> 
> 
> ______________________________________________________________________
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers