Update developer README from Sourceforge to GitHub

[Sobuno]

Currently the developer README references Sourceforge. This is a bit outdated since we are using GitHub now. The documentation should be updated to reflect this, and the guide for integrating version control into Eclipse rewritten from Sourceforge to GitHub as well.

[cbortz]

+1 I also recommend having at least some form of a README in the root directory of the project, including details on submitting issues and issuing pull requests.

[Sobuno]

@cbortz, feel free to come up with a README for that, I have little to no experience with issue tracking and pull requests actually since I have never had any contributors while the project has been located here.

[cbortz]

@Sobuno Sure thing. I must say, though, I am no Java engineer. If you have any guidelines for code standards (spaces instead of tabs, newlines at the end of file, etc), it would be greatly appreciated!

Also, can you detail the requirements for developing on the project? (java version, windows version, recommended IDE, etc)

[Sobuno]

I am compiling against Java 1.7 (aka Java 7), so that is the requirement for both developing and running SWGAide at the moment. If we need any features from Java 8, we can probably easily switch to that.

As for Windows, there should be no requirement as far as I know. My machine runs Windows 10, but I have maintained it under Windows 7 as well and I know it works under XP and Vista too.

IDE-wise, I use Eclipse, which if you read the current developer README was also the choice of Zimoon. I've attached his recommendations regarding coding style and IDE settings for Eclipse below. The code style for Eclipse is attached as a file: SWGAide_code_formatting.zip

Zimoon (The original developer) wrote this in a private SWGAide Developers forum once. I am trying to keep as much information in the open as possible, however, so here it is again. Only change is to format it according to GitHub markdown:

In Eclipse it is possible to have one style per project, use the attached code style file for SWGAide.

This will reduce the amount of code that is reformatted and uploaded to SVN just because we have different standards and happen to let Eclipse sort and/or format the code, which we should do regularly when developing. I know I have done many mistakes in this regards but now I try to keep these happenings to single commits and not with code changes and I try to format only the element I work with, touch wood...

The following is my settings for warnings and errors:

Menu Windows (or Projects if you want) > Preferences: Java > Compiler >

##Errors/Warnings##

Code style
  All warnings but not
  unqualified   I
  non-ext str   I

Potential programming problems
  All warnings

Name shadowing and conflicts
  All warnings
  Check-box not selected

Deprecated and restricted
  depr API                W
  signal use of depr API [ ]
  signal overriding depr [X]
  forbidden reference     E <<<<<
  discouraged reference   W

Unnecessary code
  All warnings
  only one selected check-box:
  "ignore overriding and implemeted"

Generic types
  All warnings

Annotations
  All warnings
  Selected checkbox: "Enable @..."

Check-box: "Treat errors fatal..." not selected


##Javadoc##

  All of the check-boxes selected

  malformed javadoc          W
    only consider members... Private
    missing tag desc         validate all standard

  missing javadoc tags       W
    only consider members... Private

  missing javadoc comments   W
    only consider members... Private


##Task Tags

  FIXME -- high
  TODO  -- normal
  XXX   -- low
  case sensitive [X]

I want to document the classes, members, and methods so any new developer can quickly get going. This is perhaps not your way of developing but I ask you to add at least a few words wherever there is a warning. It is better to understand than not to, right?

Variables and Methods
Short names in the local scope, otherwise descriptive names, Java style.
As far as possible, use private and final qualifiers. Relax later later if necessary.
Keep model types as simple as possible, null is accepted, or constants such as Collections.emptyList()
Place control logic closer to where it is used, never return null unless asked for or very local.

General Comments
Use listener patterns rather than to push data.
Store simplest possible structures in the DAT file, not referencing objects only created with the GUI.
If uncertain it is better to ask and discuss at the forum than ...

If anything is weird or stupid in my thoughts, yell at me 8)

Greetings
/Zimoon

PS: Remember that a lot of stuff in SWGAide was developed long before I formed the above "rules". It will be fixed in due time but there is no rush.

[cbortz]

👍 thanks

[Sobuno]

@cbortz, I updated the comment to include the file and answer the rest of your questions, was a bit too hasty initially.