commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Haifeng" <haifeng.c...@intel.com>
Subject RE: [crypto] The standard indentation is 4 spaces per indent
Date Fri, 29 Apr 2016 02:09:35 GMT
Mixed whitespace styles should be definitely avoided in anyway.
Do we have to change 2 spaces indent to 4 spaces? Uma suggest we keep the original 2 spaces
style. That makes sense.

Any folks have objections?

Thanks,
Haifeng

-----Original Message-----
From: Matt Sicker [mailto:boards@gmail.com] 
Sent: Friday, April 29, 2016 9:00 AM
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [crypto] The standard indentation is 4 spaces per indent

If you want to prevent mixed whitespace styles and whatnot, you can use EditorConfig <http://editorconfig.org/>.

On 28 April 2016 at 19:06, Gangumalla, Uma <uma.gangumalla@intel.com> wrote:

> I am ok with a JIRA and type could be task for the reasons Sebb 
> mentioned below.
>
> But I prefer to keep 2 spaces if others also ok who is going to 
> involve in development. I assume most of Hadoop devs would have set 
> their indentation
> 2 already in their IDEs. So, here also most of them would involve with 
> indentation space 2 in their IDEs. If that does not hurt other, how 
> about keeping 2?
>
> It will make easy to identify the default tabs(tab with 4char space) 
> from IDEs like eclipse if code format settings are with 2 spaces. Ex: 
> When some new contributor forgot to modify their IDE setting with 
> spaces, then code will be easily identifiable if that has default 
> setting with tabs. But with 4 spaces, it will look same.
>
> I just read it from Commons site: (Copied from site
> https://commons.apache.org/patches.html)
> Respect The Original Style
> Please respect the style of the orginal file. Make sure that your 
> additions fit in with that style.
> Every component has coding conventions and every contribution is 
> supposed to adhere to them. You might find it a little difficult to 
> discover the conventions used by a particular component but if you 
> stick to the style of the original then that'll be fine.
> If a patch is submitted which doesn't satisfy the component's coding 
> conventions, then either a committer will need to rewrite the 
> submission or it will be rejected. Getting it right in this first 
> place will save you having to rewrite it.
>
> It says that we can continue with original coding format if we want. 
> But anyway we can decide now.
>
>
>
> Regards,
> Uma
>
> On 4/26/16, 3:06 AM, "sebb" <sebbaz@gmail.com> wrote:
>
> >On 26 April 2016 at 03:07, Chen, Haifeng <haifeng.chen@intel.com> wrote:
> >> Hi Gary,
> >>
> >>>> Do you really want this level of Jira tracking? It seems over the 
> >>>>top to me. Is this process style for this component? In this case 
> >>>>I would just do it and not Jira it. Then for detailed history, you 
> >>>>just look at the commit history. Or are you just using Jira as a 
> >>>>to-do list in the early days of this component in its new home in Apache
Commons?
> >> As when we are working in Hadoop projects, we need a JIRA to start 
> >>a work and communicate with the community. I am not sure whether 
> >>Apache Commons allows commit of code without JIRA at this project 
> >>stage. So I just try to do it in a safe way in a new family:)  If 
> >>Apache Commons folks thinks it's OK to do it without JIRA, I am OK 
> >>with it.
> >
> >If a developer spots a typo or missing/unclear Javadoc, I would say 
> >just fix it rather than raising a JIRA.
> >
> >This case is borderline to me since it affects the whole codebase.
> >And the change impacts on how easy it is to see where/when changes 
> >were made.
> >(This is more intrusive than a package name change at least as far as 
> >history is concerned since every line may be changed) Also it ideally 
> >needs to be co-ordinated with other changes.
> >
> >So I think it would be wrong to commit the change without some prior 
> >notification.
> >This can either be a JIRA or agreement on the dev list.
> >
> >> Regards,
> >> Haifeng
> >>
> >> -----Original Message-----
> >> From: Gary Gregory [mailto:garydgregory@gmail.com]
> >> Sent: Tuesday, April 26, 2016 9:53 AM
> >> To: Commons Developers List <dev@commons.apache.org>
> >> Subject: RE: [crypto] The standard indentation is 4 spaces per 
> >> indent
> >>
> >> Hi,
> >>
> >> Do you really want this level of Jira tracking? It seems over the 
> >>top to me. Is this process style for this component? In this case I 
> >>would just do it and not Jira it. Then for detailed history, you 
> >>just look at the commit history. Or are you just using Jira as a 
> >>to-do list in the early days of this component in its new home in Apache Commons?
> >>
> >> Gary
> >> On Apr 25, 2016 6:47 PM, "Chen, Haifeng" <haifeng.chen@intel.com>
> wrote:
> >>
> >>>>In our coding guidelines [1] we say that "The standard indentation 
> >>>>is
> >>>>4
> >> spaces per indent - but respect the number of spaces used by the 
> >>original."
> >>>>The [crypto] Java code I've seen to far is all 2 spaces per indent.
> >>>>I think now is the time to do this, most IDEs can do a one-shot 
> >>>>format of
> >> a whole source tree.
> >> Good catch, Gary. The original code was based on Hadoop format 
> >>style which is 2 spaces indent. I will fire a JIRA to format that.
> >>
> >> Thanks,
> >> Haifeng
> >>
> >> -----Original Message-----
> >> From: Gary Gregory [mailto:garydgregory@gmail.com]
> >> Sent: Tuesday, April 26, 2016 6:25 AM
> >> To: Commons Developers List <dev@commons.apache.org>
> >> Subject: [crypto] The standard indentation is 4 spaces per indent
> >>
> >> Hi all,
> >>
> >> In our coding guidelines [1] we say that "The standard indentation 
> >>is 4 spaces per indent - but respect the number of spaces used by 
> >>the original."
> >>
> >> The [crypto] Java code I've seen to far is all 2 spaces per indent.
> >>
> >> I think now is the time to do this, most IDEs can do a one-shot 
> >>format of a whole source tree.
> >>
> >> Gary
> >>
> >> [1] https://commons.apache.org/patches.html
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org Java 
> >>Persistence with Hibernate, Second Edition 
> >><http://www.manning.com/bauer3/> JUnit in Action, Second Edition 
> >><http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


--
Matt Sicker <boards@gmail.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Mime
View raw message