This thread is being started for a discussion on how to best handle IDE
specific files for cardme. Currently you will notice that there are certail
Eclipse files committed in the SVN directory. This has not been done by
accident, but as a temporary solution.
Here are the list of points that I was aiming to acheive when doing so with
Maintain a standard coding style for the entire project. This maintains code readability to attract developers to read the source and perhaps join in and submit patches.
Maintain quality of code by forcing eclipse to generate warnings and errors on certain coding techniques (ie, unused imports, redundant null checks ...etc)
I have had developers in the past commit code with varying styles which I had
to revert. Which is why I accept patches first before giving anyone commit
access. It's a bit like an evaluation.
mangstadt has posted on our tracker
It is actually good practice to remove IDE-related files from source
control because these files are developer-specific. Each developer may use
a different IDE or prefer to use different project settings. You can use
Maven to generate the Eclipse project files for you: "mvn eclipse:eclipse"
And I agree, but also wish to address the above 2 points. So lets see how we
can do this. All suggestions are welcome!
What I'd like to see is that the critical files that you want for things like
style get renamed to something like:
But the real file is put in the ignore list. For somebody to use the template
file, all the do is make a copy and remove the file extension.
That way people can use the styles you provide, but it doesn't get constantly
overridden by multiple developers.
My two cents :)
I agree with #1. I think it could be helpful to have an Eclipse code
formatting file included with the project (from Project Properties > Java Code
Style > Formatter). That way, the code will look more professional because it
will be uniform in its style.
You can also export a config file for the Clean Up settings in "Properties >
Java Code Style > Clean Up". I would enable the setting that requires braces
be used in if/else/while/for blocks and also the setting that converts old-
style for loops to foreach loops.
If you want to keep the Eclipse project files there, you should change the
class file output folder to "target/classes", since the project uses Maven
(it's set to "bin" right now).
Both suggestions are valid, I have to assume that there may be people not
using eclipse (imagine that) and thus eclipse formatting files will be useless
My only issue with the eclipse template files is that even if you use eclipse
and you get the files, they're going to be project specific. Those who find it
annoying will most likely just remove it and it'll be less likely they will
commit anything to svn, and if they do they'll need to use them anyways.
I think we can have a source jar file with just pure source code and license
and another one called distribution which will contain everything.
Forgot to mention that a developer doc going over some coding guide lines
would be useful.
Yes that would be useful. I'd love to see all the code formatted in exactly
the same way, but realize that the effort it takes to enforce this may exceed
the benefits. Creating an Eclipse code format XML file and encouraging
contributors/committers to use it would be a good middle-ground I think.
I also think Javadoc usage should be included in a set of coding guidlines. As
I've told George, I am passionate about clearly-written code. Javadocs help to
describe the purpose/function of a class/method/field without requiring the
developer to spending the time to read the source code.
It goes without saying that unit test coverage is important.
I am a Masters in Software Engineering research student and my research is on the requirements problems in the Open Source Software environment. For my research purpose I need to talk to the core members of the team. Kindly respond me at the earliest, I am really interested in gathering the information regarding your project on SourceForge.net mainly because it will be mentioned then in my Journal research paper.
Kindly, email me at:
I'll be waiting for your response core team members!