Community
Participate
Working Groups
Enable automatically formatting of source files on editor saving for all Mylyn projects.
If my opinion counts, please don't do this. Steffen you'll be the first one to complain about changed whitespaces in patches.
One reason I filed this bug is that I hope we would get less patches with white space changes in the future. It will simply automate the policy of always formatting code before check-in that already exists.
I think that it is important for us to do this in order to do this, because after the up-front cost of having to use the Fuzz Factor in patches, we will ensure that patches do not add improperly formatted code to our source code base. This has been a problem because it makes stack traces innacurate. Also, in the end means that we end up with more trouble for accepting patches, because committers will randomly end up reformatting the whole file when they get to it. We should make sure that we have as many patches applied as possible before doing this.
(In reply to comment #3) > ...it is important for us to do this in order to do this... Mik, I read the whole comment several times but still don't understand what you've been trying to say. Can you please summarize in one sentence if you are voting for automatic formatting or against it. Thanks.
Sorry if it wasn't clear. I stated "it is important for us to do this", i.e. I'm voting for it.
Rob, what are your thoughts? In addition I would like to enable these code cleanups which will enforce coding standards that we have and enforce additional good coding practices: - Organize Imports - Convert control statement bodies to block - Add final modifier to private fields - Add missing '@Override' annotations - Add missing '@Deprecated' annotations - Remove unnecessary casts
+1 for all proposed, except perhaps "Add final modifier..", unless that's a best practice used elsewhere. Steffen: do you know what settings Platform uses?
I looked at a few jdt and pde projects but none had any cleanup or save participant rules configured on a project basis. I don't know if platform has any guidelines for this. I am fine with leaving the "Add final modifier..." disabled. It would probably make sense to run these rules on the whole code base once so we don't end up with whitespace changes in all commits after enabling this (e.g. before the next release is tagged).
May I suggest to do that after pending patches are applied
+1 for doing before tagging. This will help keep the 2.2 and later stack traces stable. Note that clean up can be invoked via popup menu on one or more source folders. Please comment before you start on this so that we can make sure as many patches as possible are applied.
I have been using (manual) code cleanup for a while now and find it very useful to add the final modifier for fields that are not muted. This cleanup makes it very easy to identify fields that change throughout the life-cycle of an object and helps to refactor classes to make them immutable which is a good practice. The cleanup can also help to identify programming errors when a final modifier is not added although it was expected (e.g. due to a missing assignment in the constructor). Unless there are objections I would therefore like to enable the "Add final modifier to private fields" cleanup. To avoid "breaking" 2.x stack traces the code clean up will happen in HEAD as soon as 2.3 is released and branched. We will go through the outstanding patches before that and determine if they should be applied before the cleanup.
Sounds great.
I have enabled the clean up and applied it to all plug-ins in HEAD except for bugzilla (bug 221043). The code has been tagged with these tags: bug_210040_code_cleanup_before bug_210040_code_cleanup_after
Done.
Hmmm, interesting, in this case I quite like the association between the tag and the bug that describes it.
