In projects with many developers it is useful if all their IDEs are configured with identical code style settings, such that you won't get pseudo-differences due to changed formatting checked into version control whenever someone else changes your code. You can try to convince everybody to import project standard formatting settings, but they might forget to do that on creating a new workspace and forget to adapt them whenever a change is necessary, so this will get lost over time.
So, is there a simple way to automate things such that everybody has the same settings and gets his settings changed automatically if they need to be updated - without them taking any action on their own?
Many of these settings are stored in .settings/org.eclipse.jdt.ui.prefs if they are configured project local , so it would be feasible to checkin this file into version control but leave out the other files in .settings. Unfortunately the formatter settings are contained in the big bucket .settings/org.eclipse.jdt.core.prefs, so you would have to do more complicated things to update these. So I am wondering if there are simpler / other options.
Clarification: In my experience many developers ignore requests to adapt the various code style settings in eclipse since they consider them unimportant. So I want to make it at least extremely easy for them to use the project standard settings, at best the codes style adaption should work completely without their cooperation - especially on updates of the coding style. I am looking for tools to do that.
Warning: it's not a good idea to be too strict when it comes to code style. Many programmers have a strong own style. So be careful what you wish for.
The easiest method in Eclipse is to create an empty workspace and use that initially by simply copying it to the developer's machines. You could even copy Eclipse with all the plugins. This has the drawback of having to manually create changes. It is also the most restrictive option.
Another method is to export/import all the settings. This is a bit more work, but it is less restrictive. You would need to distribute the following settings: Formatter, Clean Up, Templates. Furthermore you still would have to set the max. line size in the general settings.
The best way to let people adhere to code practices is to create a document about the minimum requirements. Make sure you document your decissions and let people participate. Then check if people adhere to it; if you let let it slip programmers will go their own way. Management (unfortunately) has a role to play here.
The best way of enforcing the code style is to create a CheckStyle configuration and keep it as a read only file on disk. You can then use this as an external style sheet from the CheckStyle plugin. Make sure that the Eclipse formatter and clean up settings match though.
The same CheckStyle configuration may be used on an automated build environment to generate warnings and errors. These warnings and errors should be discussed during review. Make sure you have loopholes, rules should ne broken if the need arises.
Managing developers is "not unlike herding cats"
In my old company, we would create a "default" or "template" workspace where everything is configured according to personal taste (like key settings, view positions etc.) and according to the companies rules (formatter, compiler warnings, checkstyle, mandatory plugins etc.).
Every time I needed a new workspace, I just duplicated this template workspace.
Since starting from scratch with a new workplace is such a pain, people automatically got used to using the template, rather than creating a complete new workspace. So there was never a problem with people forgetting it.
Related
Is this possible? If so how do I do this?
The code is in C# and we are using TortoiseSVN.
I simply want to auto format the code on every checking.
Thanks a lot
With a pre-commit hook script, you could do that, yes.
But I'm sure that you will remove that script after the first commit because you'll get into big problems.
If you modify the data that gets committed, the client doesn't know about that. So after such a commit where your script 'fixes' the formatting of a file, the file content in the repository is different than the files in your working copy. But your working copy still thinks it's up to date with the repository (after all, it's modifications just got committed).
So on the next update, you'll get into hell - broken working copy, angry users, ...
And of course, you might break the build - auto formatting has that effect sometimes.
You can of course implement a hook script that checks for a correct formatting and returns an error if it doesn't, that's perfectly fine.
And since you're using TortoiseSVN, you can try doing the formatting in a client-side pre-commit hook.
You're touching on holy-war ground. Mussing with people's formatting is asking for pitchforks and torches.
My recommendation: Don't.
Not to mention, if you're talking C#, and your developers are using Visual Studio, VS has a lot of auto-formatting tools. Just by entering that closing curly-brace and VS can/will auto-format your code.
A better solution may be to get all your developers to use the same auto-formatting settings.
Tools -> Options, Text Editor -> C# ->Formatting
These settings are exportable, so if you can get the team to agree to use the same code-formatting settings in VS, you can avoid the trouble of performing it in your source control system which is better left to do what it does best.
If you're hell-bent on doing this, a pre-commit hook, like others have said, is the way to go. If you're SVN server is running on Windows, might I recommend CaptainHook for writing your hook scripts? Plugin-able hookscripts that you can write in any .NET language.
like most people here I agree adding a pre-commit-hook that rewrites their code is bad, however you can have a pre-commit hook that rejects code that is not formatted to your coding practices and inform the user of such error.
I think you can do this using a pre-commit hook in your repository.
Edit To the people who think this a bad idea (I'm not saying it isn't): It's not uncommon for organizations to enforce a specific code style or code formatting. Sometimes these rules can be quite pedantic and strictly enforced, and although they are usually human actions involved in this (i.e. formatting to the correct style before you commit anything to the repository), automating the process can sometimes be useful.
An alternative approach might be to do the verification automatically before the commit, but still allow the commit even if the check fails, but then only send an e-mail or some other notification to indicate that someone didn't follow the style.
I highly recommend it.
Use a pre-commit script or better still, find a way to do it automatically in your IDE (pre-commit will push the changed file to the client). Eclipse can auto format on save.
The rationale for this is that if developers format differently you'll find files which have commits on them where the commit is only a formatting change and it will cause endless confusion.
A common formatting pattern is a very good idea. It'll be hard to introduce, but it'll be worth it. All changes will be real changes, and not just formatting changes. In my experience developers will see the benefits and accept it.
I've worked with cvs and java and used jalopy to auto format. We were using a branching system so it was mandatory, and it worked very well.
It is possible, but also a very, very bad idea.
No automatic code formatters are perfect, and I can almost guarantee that it will tick people off.
That said, if you want to do it, look into using pre-commit hooks.
Is the SVN server running on a Windows or Linux system? And what code-formatter do you want to use?
This question comes from previous experiences with svn.
We had a problem where our code was badly formatted, mainly because of the increase in developers at the time who did not adhere to our formatting guide for various reasons. So there was discrepancies in code formatting for quite a bit of time. Additionally the codebase was quite old as well, so it was probably going on for years.
Anyway, there was a suggestion to format all touched classes in new features into our agreed standard code formatting style. Other developers were against this mainly because:
You can't use an annotation style view of the code, so you can't see what features a particular line of code is related to.
In the end, we ended up rejecting this idea and only did formatting for newly introduced class files. For new code in existing classes, we only ensured that the lines that were edited were indented correctly.
We are mostly eclipse users, but I think that this feature is available in other ide's as well (just checked online for netbeans and intellij).
For an additional bit of context, the codebase in question was fairly mature and there was a fair balance between support work and new feature work. Sometimes new features were split into phases, so this is also something to consider.
So the question(s) are:
Was this the correct approach? Is it reasonable to reject "code formatting commits" just to preserve an annotated view of the code?
Are there better ways of doing this? My opinion here is that maybe there should have been a commit hook that does automatic formatting, not sure if something like this is exists or is even valid though?
You do not want to do this in a hook. Not only is it a really bad plan to have a hook edit the source in any way as it's in transit, but the error the user will get is going to suck (it would be impossible to tell the user all of the errors in a meaningful way on an error message). I'm not a fan of enforcing style in general.. but if you must, I recommend a three part plan
Define and document your coding style. What you come up with isn't as important as the discussion.
Export configs for editor and share with team. this will be editor dependent. you want to make it stupid easy so that the drudgery of indentation and other syntax things is handled automatically.
Have your CI enforce that style. If you really want to enforce it, you'll do it here. likely with something like checkstyle. This will generate a fancy report that will show and display all the errors.
I've worked on teams that did this really well... the standard was pretty flexible, everyone felt they had input so when the build failed there was no grumbling. We fixed it and moved on.
I did work on a team where an irrational fascist believed that the style was more important than the completeness or correctness of the code. It sucked.
Personally I'd stop at step two and see where that gets you before moving on to step 3.
In Eclipse, under Preferences > Save Actions, one can enable the Auto Formatter which formats the code on file save. You can configure a set of Formatting Rules and Export Preferences File to send to your developers (or have the leading developer do it) for them to Import Preferences File, so the code is automatically formatted as they are developing it.
A standardized auto-formatter would help eliminating the in-similarities in code style which causes non-codebase changes in the SVN.
I think it would be perfectly fine to do a one off code formatting commit for the old classes in your repo, it's definitelly better then having ill-formatted code all around the place.
As for IDE's Intellij and Eclipse can do formatting on save, but I'd be against doing it in a hook because it's not aware about what you're coding in, and wouldn't trust that on a script. But that can work as well but need to make sure that what you're using for formatting is well up to the task
I started to work with a group of five new programmers on a large project. I'm looking for the best way to share the source code between all the members. Each person is modifying different parts but all parts are related. I'm looking for a platform or way that when I change any parts of code they can see it on-line or as soon as possible.
Currently we conflicted with each other. For instance I worked on the parts of the source code and when I finish my job and I went back to our subversion repository which is google code to upload the new version. Then I realize someone else has been edited the code! What can I do in this situation?
We are using netbeans and everyone is working far away from each other so we can not have a face to face meeting.
You write about your subversion repository: well, that's good, because version control software is exactly what you need.
Conflicts can appear when people work on same parts of the code, but usually this doesn't happen too often. If it does, you should talk with your team members and set up a policy to update their local working copies more often. Another idea would be to set up subversion to send out e-mail notifications whenever someone commits changes.
When a conflict appears, the one who updates his local working copy has to resolve the conflict. Resolving doesn't mean to overwrite other people's work but to adjust local changes so that they work well together with the code which has already been committed to the repository by someone else.
If a lot of people are working on the same classes Subversion does a poor job of merging and as a result conflicts occur all too frequently. When conflicts do occur, the only solution is to resolve them - most IDEs have tools for this, as does Tortoise.
There's a few things you can do as a team to minimize conflicts:
change the minimum amount of code (avoiding formatting changes)
check in small changes
check in often
sync often
This does mean you have to be careful with your changes, so like everything in development there's trade-offs.
An alternative is switch to a distributed version control such at Git. DVCS is based on the need to merge and so do a far better job of it.
I'm working in Java development. I have recently come into a situation where I have to comply to coding standards: member and method ordering, naming conventions, modifier sequence. I am thinking about methods to either automate checking for compliance, or generate some sort of mechanism that does the reordering.
We're developing with Eclipse, but the technology would be open. One way it might work is to generate an external builder tool and add this to the projects. The disadvantage would be that it would automagically apply to all files, which could run into problems with legacy code, blowing up the error count to a degree where it is no longer a sensible metric of compliance. Also, it makes code reviews much more difficult, which is not wanted.
Another way would be some kind of parser with only informative capabilities. We could run a process inside Jenkins, and that certainly would work, but that would also mean that the code had already passed a review, which is usually a little late for a code compliance check.
Are there suggested or even easy methods to integrate such functionality into either IDE, the source control system (Mercurial) or even Jenkins? How is this enforced elsewhere?
I would not recommend doing such changes automatically. Even though most of the checkstyle/pmd complies are valid, it happens to me that I need to ignore some of the warnings/errors. Moreover - there is only very small pool of such easy issues. Most of the notifications require more complex operations and probably couldn't be done without human interaction.
I'm using Sonar integration. It contains many external checkers like PMD, CPD, Checkstyle, Findbugs and can integrate with some other useful tools like Cobertura (test coverage statistics). Its almost trivial to bind Sonar build to Jenkins build and trying to avoid major/critical issues might be considered as a good approach.
In developer environment I use Eclipse integration with findbugs. There is also some point of integration with sonar but it requires either submitting the code to server or running server locally, which I personally don't like. However after few cycles of polishing the code after code review in Sonar you will notice that you (and other team members) stick to most of the rules and checking reports on daily basis is enough.
One solution is to use JCSC / checkstyle or other tools that are command line friendly. Integrate this with your build process. Individual developer runs this on his branch.
Most tools integrate well with Jenkins (via plugins), which can be used as dash board
Further to #Jayan's answer, Jenkins has a CheckStyle plugin that will display the results of each CheckStyle run and let you set the build status depending on how many violations are found. So your setup steps would be:
Set up your CheckStyle rules to fit your coding standards
Add a step to your Jenkins build that runs CheckStyle
Add a post build step to publish the CheckStyle results.
Jayan mentions checkstyle, which is great for checking against coding standards.
I remember using Jalopy years ago for automated code formatting, it might suit your needs as well.
In all honesty though, I wouldn't reformat the code automatically. Using tools such as checkstyle to raise warnings is one thing. Taking control of a developer's source code is quite another, and most people find it terribly intrusive and unpleasant.
Also, a bug in a code checker will at worst generate incorrect warnings. A bug in a code beautifier might corrupt and destroy hours worth of work.
You can use JArchitect to check your best practice using CQLinq queries which is useful
to create easly your custom rules
JArchitect is free for open source contributors :http://www.jarchitect.com/JArchitectForOSS.aspx
I know there are some similar questions around in Stackoverflow, but they were either .Net related or didn't have any answer that helped us.
The case is as follows: with some friends we are starting an open source project. While setting the foundations of the hopefully successful project, a question arose: how to enforce the code conventions of the project?
The reasoning is that being an open source project, if people starts reformatting the code as they like, the patches will become cluttered with changes due to formatting that will hide the real "value" of the patch. So we want something that forces users to abide to a specific formatting, breaking the build if they don't.
The project is using Struts 2 + Spring + Hibernate, using Maven 2 (thinking on moving to Maven 3). We know we can use "CheckStyle" to test the Java files, but this leaves some questions open that hopefully someone can answer:
There is some tool to check the style of XML and SQL files, breaking the build if they don't abide to the rules?
There is some tool that automatically reformats the source files (Java, XML, SQL) to the desired convention? Can ti be integrated with Maven somehow?
We could find Jalopy for Java files, but we would prefer a free tool (as far as we know, the latest version is paid one). And we still couldn't find anything for SQL/XML.
UPDATE: just to make it clear: I'm not asking about PMD, Checkstyle or these tools. I'm asking for tools that:
Automatically format SQL, XML and/or Java files to a desired coding convention (4 spaces, etc)
Detect SQL and XML files with the wrong format and break a build because of that.
The standard tools I would use for java are
CheckStyle
FindBugs
PMD
All of these are capable of failing a Maven build when a certain threshold was reached.
But the question is of course: who runs those tools, and when?
My suggestion would be to get a Continuous Integration Server like hudson and configure it to run the maven checkstyle, findbugs and pmd goals (hudson has plugins to display graphs for all these tools), and you will always see who failed the build, because you can see who committed what between two builds.
It sounds to me like you're going along the route of creating an open source project and then giving commit access to all. I'd advise against this, whatever measures you try to put in place, someone stupid will come along at some point and sod the whole lot up.
Instead, I'd advise taking a different approach with commit access and handing it out only to people that prove they pay attention to the rules and restrictions you've put in place. They can generate patches, submit them to you and eventually if they're regular and trustworthy enough, you can hand out commit access.
One other point, something like Hudson may be of use here (it has a checkstyle plugin as well.) It won't prevent people committing crap code, but it can create a build and run checkstyle every so often, notifying people on a mailing list if someone screws up the code (either because it won't build or because someone's broken checkstyle rules.) Not foolproof, but this would enable you to keep an eye on things more easily.
Each of PMD, Checkstyle, Findbugs etc have Eclipse and other IDE plugins. You can also configure your IDE of choice to format according to the style you want, and then share this configuration (as a file) among members of the team.
I don't think you want your SCM server formatting files for you, otherwise after a check-in your local copy might be immediately out of date with whats in SCM. Everyone on the project would have to get used to doing an update immediately after a commit then, which sounds like a brittle process.
Instead, share your IDE configuration with the team (checking this config file in would be a good idea for what you want) and then fail the build if anyone violates the policy.
Yes, since eclipse, for example, has a build-in code-formatter, it could be possible that you may use the formatting-plugin to format all the java-code along a fixed configuration file, even without eclipse or any other GUI in a build process.