| 提交 | 用户 | 时间 | ||
| 58d006 | 1 | Since gmaps.js has been created to accomplish some goals about simplicity and cleanliness, the contributions must be guided by some rules, in order to keep gmaps.js simple to use and brief in code. |
| A | 2 | |
| 3 | ## About requirements | |
| 4 | ||
| 5 | gmaps.js only requires JavaScript, so new features must be written in plain JavaScript and shouldn’t depend of external libraries like jQuery, Prototype, etc. | |
| 6 | ||
| 7 | ## About examples and documentation | |
| 8 | ||
| 9 | Big changes, like support for new libraries or services, or custom features, need an example file (or files, depending of the magnitude of the contribution) and an entry in the documentation page. | |
| 10 | ||
| 11 | The example file must be included in the branch `gh-pages`, and be linked in the examples page. Example file in the `master` branch is optional. | |
| 12 | ||
| 13 | The documentation must explain in an simple way any argument passed in the method, and tell if it’s argument is optional or not. No examples are required here. | |
| 14 | ||
| 15 | ## About new features | |
| 16 | ||
| 17 | The main goal of gmaps.js is to have full support to all features of native Google Maps API, so the primary goal of the contributions to cover the missing features. But other contributions are welcome. | |
| 18 | ||
| 19 | If the new feature has a functionality different from strictly work with maps (like animations, custom infoWindows or support for external services), it would be ideal to create an extension with this feature. | |
| 20 | ||
| 21 | ## About coding standards | |
| 22 | ||
| 23 | * Default values must be defined. | |
| 24 | * Functions must end with semi-colon. | |
| 25 | * Function names in camel case. | |
| 26 | * Two space for indentation. | |
| 27 | * Use strict mode syntax. | |
| 28 | * Don’t use prototype object to extend gmaps.js (except with extensions). | |
| 29 | * Use apply for calling functions. | |
| 30 | ||
| 31 | _**Thanks for contributing with gmaps.js**_ | |
