Plus, getting used to Google Style, well, might be a good career move. :)
On Thu, Nov 6, 2014 at 10:21 AM, Eric Dalquist <[email protected]> wrote: > +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 > > -- 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
