Prince of all Goldfish
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2950
|
1. C++. If you'd prefer to develop a different language plugin for ENIGMA, we'd be happy to support it, but the work would be enormous (Unless you're interested in continuing the existing, but very early, JavaScript port).
2. Git's pretty easy to pick up on. Most of us learned from small tutorials on the internet; I can't find the one I used, but I'm sure the others are just as good.
3. You can start flamewars asking what constitutes "Good coding practice." I can't even tell you "just comment your code well," because lately, the trend has been "self-documenting code," which uses functions so tiny as to be self-explanatory. In the words of my journalism advisor: just try not to suck.
4. It is certainly preferable to use Linux, as the package manager can fetch and set up all your tools for you. However, a good number of our developers use Windows, and MSys-Git comes packaged with the ENIGMA zip.
The basics of Git are pretty simple. The idea is this: everyone has a local copy of the entire git repository, history and all. Because of this, no one versions binaries; doing so causes terrible bloat, as you have all the previous versions checked out at all times. On the plus side, you can commit and use all features of version control locally. Everyone can, even without having repository access. You only need credentials when you're ready to publish your changes.
When you obtain changes from the Internet, it's called a pull. So basically, we enact changes, you pull them. When you publish changes, it's a push.
Our publishing is handled through GitHub. GitHub makes it easy to fork a repository; you just sign in and press the "fork" button. A fork is just a copy of the repository which you own entirely; you are free to make any modifications to it you like (per the terms of the license of the code, which, in our case, is GPL). When you are satisfied with the changes you've made to your fork, you can drop a pull request to the owner of the repository (in this case, us), and after reviewing your changes, they'll decide whether to accept, or pull them.
When I go to commit changes, I usually start by running [snip]git status[/snip] to see what's changed. That way, I can see if I'm about to accidentally commit a file that doesn't belong in the repo. You'll notice the Windows developers use a UI frontend for git, and carelessly commit binaries to the repo all the time. By listing the files before committing them, I usually avoid that. After checking status, I run [snip]git add --all[/snip] and then [snip]git reset HEAD <file>[/snip] for any files I didn't want to add, if any. Usually, those files go in .gitignore, a file listing what files and directories git should ignore. After that, [snip]git commit[/snip] or [snip]git commit -m "My commit message"[/snip] to commit them, and then [snip]git push[/snip] to publish them, if they're ready.
Words of caution: I think the git checkout command is one of the few commands capable of destroying something you've worked on. I have never found a way to undo it.
As far as developing, I don't really have any words of caution for you. Something to note is that if a check needs done to avoid users performing invalid operations on something, we try to confine those checks with [snip=CPP]#if DEBUG_MODE[/snip], so as to avoid slowing the engine down on trivia where the check takes longer than the operation.
|
