-
Notifications
You must be signed in to change notification settings - Fork 18
How to Contribute
Read: https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
Developers spend about 25% writing code, but 75% reading it. Writing readable code saves a lot of time.
- Keep the coding style consistent
- Prefer longer, unambiguous names over short but ambiguous ones
- Prefer slower but easily readable code over short/fast but hard to read code (if it doesn't noticeable affect performance)
- Even small things matter; If a character (e.g. whitespace) is superfluous, remove it, if it is missing, add it.
While quick and dirty implementations may save time in the short run, they will cost more in the long run.
- "Quick and dirty" is almost never an option, there is only "clean and solid"
- Always mark temporary or unfinished solutions using either TODO or FIXME with an explaining comment
- Use FIXME for code that is wrong or missing
- Use TODO for code that works, but needs to be improved
- Make sure there is an issue on GitHub or something equivalent
- Create a new branch for the feature, based on latest
develop
, e.g.feature/some-keywords
Note: Always include the issue ID in a commit comment, e. g. #23 implemented update task
We use flywaydb for database migration. If you never heard of database migration please dig into the topic, this this manual will only cover technical details.
Our migrations can be found here: https://github.com/FAForever/db/tree/develop/migrations
Naming Convention: Vxx__some-keywords.sql
A pull request typically contains one migration. The maintainer may change your filename, mostly the version.
- Nearly every table should have a
create_time
andupdate_time
column.
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
- Consider adding data for development to the test-data.sql
- Be familiar with Database normalization
- Test your migration on the test server