| Thanks, Camille.
Using the zero-blank-line formatter profile or not formatting the generated sources at all, I get even more files (585) differing from the current master only in formatting. Using the default Eclipse formatter profile, I get 586 files changed.
I guess I'll just wait until we have rebased the standard policy.
cW
Hi Christian, hi all, Currently, we use a specific code-formatter in Papyrus, which, for some historical reasons I don't know, is quite different from the default Eclipse one. To avoid messing with major ongoing refactorings, we wanted to wait for all M6 improvements to be merged into master, before switching to a more standard Java code formatter (Although still not the default Eclipse one). When we'll do the switch, I'll apply the formatter to all Papyrus Java files (IIRC, the new formatter is almost compatible with the former one, i.e. there shouldn't be any change in the line breaks; only in the whitespaces) Then, we also have a second formatter, dedicated to generated code, which removes all multiple blank lines (Zero Blank Line formatter, in the formatter folder). The reason is that generated code may produce a lot of useless blank lines. We always apply this formatter to generated code from diagrams. However, XText and EMF Generated code is much cleaner, and usually we don't format it at all (or we use the default Papyrus formatter). Regarding the Autocrlf, most people in the Papyrus team are using EGit and Windows. We've noticed that removing the autocrlf option was the only way to avoid the merge errors due to files being committed on Linux. We didn't try to enforce a common setting for everyone. That's something we may want to do when we switch the code formatter. Regards, Camille
Hi Christian There seem to be conflicting recommendations on autocrlf for Windows, so I don't know what to do. So I leave it unchanged as I think should be the case for any non-project persisted setting. For OCL, all projects are set to Unix, UTF-8 so most tools respect that and get it right automatically. I'm steadily reporting bugs on tools that don't. Occasionally I need to do a convert-all to Unix to see what CRLFs have leaked. Regards Ed On 19/03/2014 16:33, Christian W. Damus wrote:
Hi, Team,
What is our policy vis-a-vis formatting of generated code? Is it
- don't format the code: let GMF/Xtend just produce whatever it produces, or
- format the generated source tree using your own preferred formatting style, or
- format the generated source tree using the Papyrus Formatter Profile
Naturally, I would vote for the last option to ensure consistency. :-)
I ask because I changed the DiagramUpdater template on a branch to change how it finds inverse cross-references and regenerated the class diagram, then formatted the code with the formatter profile from
doc/DevelopperDocuments/templates/Papyrus Formatter profile.xml
in the git repository. The result was 576 files changed only by differences in the formatting, not the substance.
While we're on the subject, I often see commits that have lots of changes only in formatting (conforming to the above-mentioned profile). I have so far resisted configuring the JDT's "save action" for formatting the file because I didn't want to introduce noisy changes into git, instead only formatting the locality of each of my edits. It would be nice just to let the editor automatically format everything so that we can gradually converge on a uniformly formatted codebase, assuming (of course) that every committer does the same, with the same formatting profile! Shall we agree to do this? Or are there other recommendations?
There is also the question of git's line-terminator settings. Those of us that are not on Windows platform often see CRLF line-terminations in the Papyrus source files. I, for one, follow the (historically) recommended practice of setting my global gitconfig to core.autocrlf=input on Mac. Does everybody on the team that uses Windows have the same core.autocrlf setting? (regardless whether it's false, true, or input, though usually Windows users set it to true)
Git has since evolved its line-terminator management strategy using a .gitattributes file in the repository to ensure that teams will have a consistent story for that repo, as described here:
Thanks,
Christian
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus found in this message. Checked by AVG - www.avg.comVersion: 2014.0.4336 / Virus Database: 3722/7214 - Release Date: 03/19/14 _______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|
