+1 to what Andrew said. I've contributed to a lot of different OSS projects pretty much every "big" project (Spring, Hibernate, Jackson, Ehcache) have strictly enforced style guides. Did I agree with all the rules of each of these style guides? No, of course not. Did that make it harder to contribute to them? No, of course not. It was just a matter of setting the style guide for the project in my IDE and letting it do the work.
The initial switch can seem like a lot of work and take some time to get used to. BUT going forward you get tremendous value out of a consistent code base. The follow on to a style guide would be running static analysis tools agains the code base as well. On Thu Nov 06 2014 at 7:56:05 AM Andrew Petro <[email protected]> wrote: > > don't like the recommendation of 2 space indent w/ 4 space continuing > indent. > > No doubt. > > But go down that road, and then we have to talk about defining style, and > your preferences, and my preferences, and then we need to maintain our own > guide, and then we need to figure out how to automate guiding adherence to > it and innovate on enforcing our own styles. > > Let me be blunt: that will fail. > > Or our entire style guide can be "We adopt Google Style." Done. Google > publishes it, Google provides the Eclipse profile that helps your IDE help > you code to the style, Google updates the guide. > > And so instead of working and innovating on defining code style guides, we > can instead work and innovate on higher education self-service and portal > experiences. Let's focus on that and delegate defining code style to > Google. > > I don't personally love every detail of Google Style. I would be elated > if we can all agree to sacrifice our personal code style preferences on the > altar of adopting Google Style as being the feasible, efficient, and > sustainable coding style to be using in our projects. > > :) > > Andrew > > > > On Thu, Nov 6, 2014 at 9:37 AM, Josh Helmer <[email protected]> wrote: > >> I mostly good with that, although I really don't like the recommendation >> of 2 >> space indent w/ 4 space continuing indent. I personally *really* >> prefer 4 >> space indent and find 2 space indent difficult to read. Other than >> that, I >> don't see anything too objectionable in the google recommendations. >> >> On the JS side, again, I'm in favor of some sort of recommended standard,. >> Something I would think is probably even more important would be a push to >> move as much of the JS out of the JSPs as possible and then try to use >> js[hl]int on the code as part of our maven build. That will catch some >> of the >> stylistic things but will also enforce best practices on the JS code (eg. >> must >> use var, must use semicolons, etc) which is probably even more valuable. >> >> It would be nice to try and move the CSS out of the JSP too. Then we >> could >> use some tooling to enforce best practices and move more of the styling to >> less. CSS is just a lot tricker to move though because of the >> namespacing >> issues unless we want to discourage the use of IDs in CSS rules (which >> might >> not be so bad?) >> >> My $0.02. >> Josh >> >> >> On Thursday, November 06, 2014 09:04:58 AM Andrew Petro wrote: >> > uPortal developers, >> > >> > I think it would be wise for uPortal to adopt tighter code style >> > conventions (and to enforce these in the release process via build >> > automation, since without automation style conventions will not be >> adhered >> > to.) >> > >> > I think those code conventions should be Google's. >> > >> > https://google-styleguide.googlecode.com/svn/trunk/javaguide.html >> > >> > https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml >> > >> > etc. >> > >> > The product has a heap of code of varying style. I'd see a changeset to >> > pervasively adjust style to the convention as only appropriate for a >> MAJOR >> > release. As in, uPortal 5. >> > >> > So. This is the initial conversation-starting email expressing >> intention >> > to advocate for this improvement for uPortal 5. >> > >> > Andrew >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] > > >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
