PHP

[jstayton]

Here's an initial draft of PHP conventions based on discussion in the GitHub Issue.

I purposely left out project-specific conventions that only apply to Monk CMS, Cobblestone, etc. Those can be noted in the project's README or wiki. I also left out conventions like code/comment line length that will be part of the general conventions.

I'll also note this in the README, but all conventions are "SHOULD BE", not "MUST BE". That is, they should be followed unless it's impractical due to it being a legacy code base or something. For example, as it's been noted in the discussion, Monk CMS can't follow PSR-2 exactly without some major changes. That's fine — follow it as closely as possible. New projects like Monk ID PHP, however, should follow it exactly since it's not too difficult getting it in line.

@shanebonham @mcordell @rickyatmonk @lefthand @etdebruin Your feedback is welcome! Please :thumbsup: when you're on board.

[shanebonham]

Do you see this being the place for us to put in-house style conventions for which PSR-2 is silent? And if so, do we have any?

[jstayton]

@shanebonham Yes, if they're global in scope. I don't have any at this point.

@rickyatmonk I think your Gulp comment got lost in the force push. It is certainly gaining momentum in JS projects, but I don't think so much in PHP projects. That said, feel free to argue for it if you think it's the better choice. I haven't tried it out.

[rickyatmonk]

@jstayton - Yeah, I haven't used either too much. I've used grunt a little more. The thing I like about gulp is that it's essentially nodejs code instead of a giant config file.

The modules exist for gulp-phpcs, gulp-phpunit. You can also wrap node module pretty easy like so

var gulp = require('gulp');
var phplint = require('phplint');

gulp.task('phplint', function () {
  return phplint('src/app/**/*.php');
});

gulp.task('default', ['phplint']);

Kenny is a big gulp fan and Scott is starting to use it in Pro Services too. Kenny pointed me to google's Web Starter Kit They are using Gulp.

That said, I do know that grunt has the bigger archive of tools. I'd be a happy camper sticking with Grunt.

[shanebonham]

This looks like a great start. I am :thumbsup:

[jstayton]

@mcordell @lefthand @rickyatmonk @etdebruin Still waiting on your :thumbsup: here.

[rickyatmonk]

@jstayton on your fist Jul 18th comment in #4 you mentioned

Use analysis and code quality tools like:

Is the value that everyone on the team knows what those are and could use them if requested. Would those be more geared towards new projects? Or, is there a workflow of usage that we ought to be incorporating even now?

[jstayton]

@rickyatmonk Yeah, there's definitely value in everyone knowing how they work. I've incorporated them all into the workflow / build process of Monk ID PHP. I'd recommend incorporating them into Monk CMS, but it's not a requirement that it be done right now. You can also start using them individually on specific parts of the system you're working on.

[mcordell]

I'm :thumbsup: here

[rickyatmonk]

:+1:

[lefthand]

:thumbsup: