Formatting standards?

[Evgeny Minkevich]

Is there a set of guidelines / standards in regards of the code formatting, styling etc?

I see quite a bit of discrepancy.

4.3.0.7:

         http://pastebin.com/vQXrAWRJ

Same piece 5.0.0.1:

       http://pastebin.com/Tcc8GSdp

And another piece 5.0.0.1:

 

       http://pastebin.com/yp8rRzus

Just a bit inconsistent - so if one uses a tool enforced formatting one would need to disable it, to be able to produce minimalistic patches...

[Matt Casters]

The debate is still ongoing but we've started to move towards a Pentaho corporate wide coding format.

It's very likely that right before we're opening up 5.1 coding we're going to reformat the whole Kettle codebase.  There are some pros and cons to the whole thing (since in general I couldn't care less about Java as a goal) but that's what's happening.

--

Matt Casters <mcas...@pentaho.org>
Chief Data Integration, Kettle founder, Author of Pentaho Kettle Solutions (Wiley)
Fonteinstraat 70 - 9400 OKEGEM - Belgium - Cell : +32 486 97 29 37

Pentaho  -  Powerful Analytics Made Easy

2013/9/23 Evgeny Minkevich <evgeny.m...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kettle-develop...@googlegroups.com.
To post to this group, send email to kettle-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/kettle-developers.
For more options, visit https://groups.google.com/groups/opt_out.

[Evgeny Minkevich]

Well, that would be great.

Matt, what do you mean by not caring about Java? 

Would it imply that it is OK to be a bit more generous with reformatting when submitting patches?

[Matt Casters]

One the one hand I obviously do care about Java as it's the tool I use every day to get stuff done.

However, I infinitely care more about that "stuff", those data integration ideas.  Java as such to me is literally nothing more than a tool with which I get things done.  If this sounds obvious, trust me: it isn't.

In the past we've seen all to often that discussions kinda float towards Java coding, cool methods of factorization, interfacing, patterns and so on.  I'm OK with any of that as long as they serve the clear purpose of making our software better and easier for our end-users.  It's a balancing act and sometimes that balance tips over to the wrong side and you find yourself re-factoring code, fixing obscure Java warnings, causing instabilities and so on, simply for the "love of Java".  That's the sort of situation you will find me fight with everything I have left in me.  

The thing is, most of the really useful contributions to Kettle have traditionally not come from Java coders, but from folks doing actual data integration jobs with sometimes only minimal Java knowledge.  However, their knowledge of DI and BI were top notch and they knew what to ask for and how it could be done through overly simplistic (OK, maybe not anymore but we try :-)) plugin implementations.  This in turn has been providing us with lots of contributions, a lot of committers and so on.  Looking at the other side of the coin, I don't think that going to github.com has provided Pentaho with any sort of developer community or made the code more attractive to a, shall I say, hacker mindset.  I don't think we're receiving all too many extra contributions because of it.

Anyway, all this just to say that, as before, every contribution is welcome.  However, we will be putting code through formatting and check-style plugins because our development teams are growing larger and more diverse so it makes sense to this at this time. (and we will be going to github for selfish reasons :-))

All the best,

Matt

[Evgeny Minkevich]

Thank you for explanation. It does make sense and resonate with me.