What to do with IDE specific Files

George_H
2012-07-08
2013-07-04
  • George_H
    George_H
    2012-07-08

    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
    cardme.

    1. 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.

    2. 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!

     
  • Michael Rimov
    Michael Rimov
    2012-07-09

    George,

    What I'd like to see is that the critical files that you want for things like
    style get renamed to something like:

    .template

    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 :)

    -Mike (R)

     
  • 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).

     
  • George_H
    George_H
    2012-07-10

    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
    to them.

    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.

     
  • George_H
    George_H
    2012-07-10

    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.

     
  • Daud
    Daud
    2013-07-04

    Hello!

    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:

    kanwaldaud86@gmail.com

    I'll be waiting for your response core team members!