Contributing to Revolution and accelerating its ETA [split from UI change thrd]

On coding standards, would it make sense to adopt a published standard such as PEAR or ZEND or some other similar?

I read what was the basis of a standard on the trac pages but wonder if a public standard would reduce the documentation load in simplify the integration of php developers from other projects.

I cannot attest to the value or qualities of the standards other than some people in group environments have found them useful.

Cheers,

Jay

I will publish the standards, but in general, the main rules will be:

a) 4 spaces per tab, no tabs period,
b) all files should have unix line endings, not mac or windows,
c) don’t reformat other people’s code; instead emulate the format they have used, and
d) don’t reformat code in check-ins where other changes are made; do them separately to reduce conflicts

I will not be adopting either PEAR or ZF standards, but some of the main points can certainly be incorporated into our own as they make sense.

I would eventually like to employ an auto-formatter on check-in so users could reformat to their hearts content when working on the code, but when checked into the repository, it would always be reformatted back to the standard format. This avoids the whole problem, and allows finicky devs to work with files in the format they feel most comfortable in.

Jason,

As I said I have only heard about the standards and it sounded like a good idea. You are a programmer years beyond my capacity so I can only defer to your knowledge in this matter.

Thanks for the standards brief though.

Cheers,

Jay

Quote from: carlholmberg at Jan 24, 2008, 03:38 PM

I have lately heard a lot of good things about TDD/Agile, but have no experience of it myself and haven’t seen any good examples of it applied to PHP. What I was wondering if the core team has any thoughts about using TDD? I assume (purely guessing here) that it would be possible to do test cases for new enhancements and bugs which in turn should make it easier for contributing developers to know exactly in what way the contributions should work and what input/return values are expected... It would also be a good base for future documentation. If I have completely misunderstood TDD/Agile and if it isn’t as good as I’ve heard feel free to completely ignore this paragraph!

I’ve worked in TDD/Agile teams in the J2EE world, and absolutely want to bring this and all the benefits it has for an open-source project to MODx. When I started xPDO development, I began with two test harnesses, one using SimpleTest (for PHP 4 testing) and one using PHPUnit (for PHP 5), but (as is typical) I got lazy and stopped following my ideal of doing true "test-first development".

That said, I have been working on an Ant-based build framework we can use to eventually achieve fully automated builds/distribution (i.e. nightlies) that fail if any tests fail and notify the offending committer. This process is also known as "continuous integration", and combined with the peer code review system (Crucible) that will enable user-submitted patches to be reviewed prior to any commits being made, should help streamline the process of contributing to the project.

But there are other issues moving forward as well; namely clearly separating core development from add-on or SDK development, and centralization of MODx users credentials/profiles (i.e. SSO to all MODx online resources). These are being accounted for and addressed as quickly as possible.

I am a bit confused, are we talking about help for Modxcms site or v0.9.7?

I aware that both end need contributors, but which one is more urgent? Personally I could love to see v 0.9.7 comes out first and fix/re-do the modxcms site later, but as as site visitor, I totally agree that this site needs an overhaul, and needs it sooner than later.

About modexcms site, Resources is a very important area, I think it will be very helpful to come out a chart (something like the browsers support for CSS chart) that indicates what changes had made to the modx codes and what are legacies codes, also a chart shows the snippets and plugins that are not supported by v 0.9.7. I think to make it easy for snippet and plugin authors for update, this can be setup as a user login area, so that authors can update their snippets/plugins info once they added support to 0.9.7.

by the way, the 0.9.7 is really look great.


.

Quote from: OpenGeek at Jan 24, 2008, 04:22 PM

I will publish the standards, but in general, the main rules will be:

a) 4 spaces per tab, no tabs period,
b) all files should have unix line endings, not mac or windows,
c) don’t reformat other people’s code; instead emulate the format they have used, and
d) don’t reformat code in check-ins where other changes are made; do them separately to reduce conflicts

Letter "a" makes me sad Especially since it uses 4 bytes instead of 1, that adds up... [i](read: http://www.derkarl.org/why_to_tabs.html)[i]

Quote from: sirlancelot at Jan 24, 2008, 08:30 PM

Letter "a" makes me sad Especially since it uses 4 bytes instead of 1, that adds up... [i](read: http://www.derkarl.org/why_to_tabs.html)[i]

I do apologize, but I’ve been in this holy war for over 8 years now, and heard just about every side of the story, but in my estimation, when the smoke clears, this quote sums up my justification for the choice.

This has been discussed repeatedly, and the answer is "If you only
work alone, never use anyone else’s code and no one ever uses your
codes, then do as you please. Otherwise use tab-is-4-spaces."

When you do Agile Programming with people using emacs, vim, nedit,
xedit, wordpad, eclipse, and who knows what else, the 4-spaces rule is
necessary for survival.

The reason is simple: People get confused, and accidentally get the
wrong tab indents when they move among editors or among settings on
the same editor. In most languages this is an irritation, requiring
some cleanup. In Python it is a disaster requiring re-inventing the
coded algorithms.

And no, this isn’t Python, but the same issues apply regarding using various editors, some that are simply inept at dealing with the problem properly.

I realize this is going to be frustrating to those on one side of the debate that isn’t going to go away, but until I have time to research and apply an auto-formatting hook on check-in, I’m going to have to ask that this be followed. Once that is done, you’ll be able to reformat it however you want when working on it.

Regarding the 4 bytes vs 1 byte argument, I do agree the space savings could be important for objects being delivered to the browser, but I’m not convinced that this point trumps the other issues. But I’m certainly not going to block any dialog on the subject, so feel free to convince me otherwise, or override my veto...

Quote from: sirlancelot at Jan 24, 2008, 08:30 PM

Quote from: OpenGeek at Jan 24, 2008, 04:22 PM

I will publish the standards, but in general, the main rules will be:

a) 4 spaces per tab, no tabs period,
b) all files should have unix line endings, not mac or windows,
c) don’t reformat other people’s code; instead emulate the format they have used, and
d) don’t reformat code in check-ins where other changes are made; do them separately to reduce conflicts

Letter "a" makes me sad Especially since it uses 4 bytes instead of 1, that adds up... [i](read: http://www.derkarl.org/why_to_tabs.html)[i]

This only really matters with HTML and JS files...and the latter will be minimized and compressed before releases.

Quote from: OpenGeek at Jan 24, 2008, 04:22 PM

I will publish the standards, but in general, the main rules will be:

a) 4 spaces per tab, no tabs period,
b) all files should have unix line endings, not mac or windows,
c) don’t reformat other people’s code; instead emulate the format they have used, and
d) don’t reformat code in check-ins where other changes are made; do them separately to reduce conflicts

I will not be adopting either PEAR or ZF standards, but some of the main points can certainly be incorporated into our own as they make sense.

I would eventually like to employ an auto-formatter on check-in so users could reformat to their hearts content when working on the code, but when checked into the repository, it would always be reformatted back to the standard format. This avoids the whole problem, and allows finicky devs to work with files in the format they feel most comfortable in.

I would think the auto-formatter would be a critical feature that should come sooner rather than later. It could easily convert tabs to spaces, convert to unix line endings, and format the code to K & R (or whatever format is decided on) when it’s checked in (or uploaded to the repository). That way, *everything* would be guaranteed to be in the same standard format and everyone could work in the format they prefer. I have the capability to configure line endings and tabs in my editor, but I’m betting not everyone has that luxury and I wouldn’t think we’d want to be ripping favorite editors out of people’s cold dead hands.

I think the development time would be recaptured many times over when you figure the hassle of dealing with non-conforming submissions and their subsequent ripple effects (not to mention the bruised toes and inflamed wrists ).

Bob

Quote from: BobRay at Jan 25, 2008, 03:42 AM

I would think the auto-formatter would be a critical feature that should come sooner rather than later. It could easily convert tabs to spaces, convert to unix line endings, and format the code to K & R (or whatever format is decided on) when it’s checked in (or uploaded to the repository).

I think selecting the K & R and in the meantime respecting the existing formatting used in the file by the author are the really critical points at this time. There are many infrastructure changes coming with the preparations for the new release, and I just can’t make researching/testing/developing such hooks a priority at the time being.

But if anyone knows of some decent, configurable "pretty printers" for PHP, JS, HTML etc. that we can easily hook into SVN, feel free to point me in the direction. Last time I started looking for something similar to the Java pretty printers I have hooked into SVN before, I couldn’t find anything like it for PHP, but it’s been a while since I looked...