I believe that we currently do not particularly care about the import order - e.g. it can be arbitrary. However at the same time we do care about keeping patches focused on given functionality and we’re discouraging unnecessary changes such as reordering the import statements. This means that one can put new import statement pretty much anywhere as long as the existing import statements won’t be moved.
I’ve opened question of applying the new code policies to existing files in the original email thread, so let’s perhaps continue the discussion there to have one thread with entire discussion? Jarcec > On Dec 1, 2014, at 11:30 AM, Veena Basavaraj <[email protected]> wrote: > > One of the reasons we wrote the coding guidelines wiki ( and we should > continue to add more of the sqoop nuances ..) is to be productive and have > agreed upon rules on coding style/ standards. > > First, Richard, Gwen for your reviews.! I am assuming the LIKE as a > positive indicator. > > I would be glad if the rest of the members can spend a few minutes on this > wiki and leave a comment on things that they want to further discuss, else > we will close this by tomorrow evening and create a formatter for eclipse > and intelliJ that follows these rules. > > > Second, there is one topic that comes up again and again in the Rbs/ > reviews and is a constant source of time sink IMO. > > So lets take a vote on how we should enforce the import order in the files. > > Here are the 4 options I suggest, if there is something else anyone wants > to add feel free to. > > > 1. We do not care about the order, so lets not bother if reorder > occurs, there are projects that follow this ( kafka) > 2. We do care, lets impose the rule going forward on any file we > touch, lets all get the formatter in place in IDE. > 3. We do care a lot, lets fix every file in the next few weeks. > 4. We do care, but lets not modify any existing file, but only > impose this on new files.( this means every developer diligently uses > a formatter and does not add code that does not follow the sqoop style > guide, it is based on mutual trust that this will happen) > > > Each of the options has its merits and demerits that are obvious. > > The vote will close tomorrow evening. If there are no votes the option is > to go with #1, the least effort and max productivity in getting things done. > > > > > Best, > *./Vee*
