+1 for standards!! On Thu, Nov 6, 2014 at 11:36 AM, Andrew Petro <apetro.li...@gmail.com> wrote:
> Plus, getting used to Google Style, well, might be a good career move. > > :) > > On Thu, Nov 6, 2014 at 10:21 AM, Eric Dalquist <eric.ape...@dalquist.org> > 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 <apetro.li...@gmail.com> >> 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 <jhel...@unicon.net> 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 uportal-dev@lists.ja-sig.org as: >>>> apetro.li...@gmail.com >>> >>> >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >>>> >>> -- >>> >>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: >>> eric.ape...@dalquist.org >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >>> >>> -- >> >> You are currently subscribed to uportal-dev@lists.ja-sig.org as: >> apetro.li...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> > -- > > You are currently subscribed to uportal-dev@lists.ja-sig.org as: > dmder...@oakland.edu > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev