Re: [uportal-dev] Adopting Google Style for next major release
The line length limit really isn't too terribly bad to get used to, and really if you consistently have lines longer than 100 characters in Java your code could probably use some refactoring to become more readable. The history part is an issue but if the refactoring was done as part of the modularization it would be much less disruptive. Move a block of related code into a new module and with that reformat it and enable checkstyle. On Thu Nov 06 2014 at 2:40:38 PM Cris J Holdorph wrote: > One other 'con' I'd like to bring up, besides Josh's (which I agree 100% > with), is the following. > > I find inconsistent style frustrating, true. But what I find even more > frustrating is when I'm trying to debug and I want to know why a line of > code was last changed. > > If you reformat the entire codebase, even for something like uPortal > 5.0. Then the history of trying to determine why a line of code is what > it is, will be difficult, to potentially impossible (depends on how the > change is made). > > It's not enough of a reason to say don't do this. But for me, it would > actually be more annoying then the style problems are themselves. > > Cris J H > > On 11/06/2014 03:32 PM, James Wennmacher wrote: > > 100 (or worse yet 80) characters on a line! Oh man! I'm going to have > > to use shorter variable and method names. At least I only need to > > indent 2 spaces now. That will help. :-) > > > > +1 on a 'common' standard, especially if we can get it enforced in the > > build (as annoying as I find that is sometimes). Google's is great. > > > > James Wennmacher - Unicon > > 480.558.2420 > > > > On 11/06/2014 08:04 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: > >> jwennmac...@unicon.net > >> 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Adopting Google Style for next major release
One other 'con' I'd like to bring up, besides Josh's (which I agree 100% with), is the following. I find inconsistent style frustrating, true. But what I find even more frustrating is when I'm trying to debug and I want to know why a line of code was last changed. If you reformat the entire codebase, even for something like uPortal 5.0. Then the history of trying to determine why a line of code is what it is, will be difficult, to potentially impossible (depends on how the change is made). It's not enough of a reason to say don't do this. But for me, it would actually be more annoying then the style problems are themselves. Cris J H On 11/06/2014 03:32 PM, James Wennmacher wrote: 100 (or worse yet 80) characters on a line! Oh man! I'm going to have to use shorter variable and method names. At least I only need to indent 2 spaces now. That will help. :-) +1 on a 'common' standard, especially if we can get it enforced in the build (as annoying as I find that is sometimes). Google's is great. James Wennmacher - Unicon 480.558.2420 On 11/06/2014 08:04 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: jwennmac...@unicon.net 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
Re: [uportal-dev] Adopting Google Style for next major release
100 (or worse yet 80) characters on a line! Oh man! I'm going to have to use shorter variable and method names. At least I only need to indent 2 spaces now. That will help. :-) +1 on a 'common' standard, especially if we can get it enforced in the build (as annoying as I find that is sometimes). Google's is great. James Wennmacher - Unicon 480.558.2420 On 11/06/2014 08:04 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: jwennmac...@unicon.net 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
Re: [uportal-dev] Adopting Google Style for next major release
+1 for standards!! On Thu, Nov 6, 2014 at 11:36 AM, Andrew Petro 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 > 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 >> 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 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/
Re: [uportal-dev] Adopting Google Style for next major release
Plus, getting used to Google Style, well, might be a good career move. :) On Thu, Nov 6, 2014 at 10:21 AM, Eric Dalquist 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 > 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 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/uport
Re: [uportal-dev] Adopting Google Style for next major release
+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 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 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Adopting Google Style for next major release
> 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 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Adopting Google Style for next major release
I agree with Josh. Also, I would prefer NOT using IDs for styling. It forces the use of CSS in the JSP, which defeats the purpose of pulling it OUT of the JSP. Pulling JS out of the JSPs will take a lot more work, though. We would need to move forward with some better JS architecture to fit the extendibility of uPortal. I’m all for it, though. Cheers, Jodie. > On Nov 6, 2014, at 8:37 AM, Josh Helmer 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: > jmuram...@unicon.net > 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
Re: [uportal-dev] Adopting Google Style for next major release
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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Adopting Google Style for next major release
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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
