> 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
