All contributors are welcome to this project in the form of feedback, bug reports and even better - pull requests. This can only benefit the 4D developer community.
Issues are used to track bugs and feature requests.
📌 Before reporting a bug or requesting a feature, run a few searches to see if a similar issue has already been opened and ensure you’re not submitting a duplicate.
- Describe steps to reproduce
- Full error message if any
- Your code if relevant
Of course you could propose a fix using pull request
- Limit the request to one feature
- Give at least one user story
- Give at least one user benefit
Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub.
- Open a single pull request for each subject.
- Prefer to develop in a topic branch, not master (feature/name)
- Update documentation where applicable.
- If any bug related, add
#<id>in commit message or pull request - Test your code
- The project is organized into folders on the Explorer home page. Please respect this.
- The project must be compilable with the "All variable are typed" setting and please don't generate typing!
- Methods must be private ie. set invisible by default, if not documented and not to be acceded from outside.
- Method must be set preemptive if possible.
- Try to be compliant with the existing namimg.
- Create a folder by category
- When it is necessary, create a
Compiler_categoryNameinside each folders for compilation declarations - Note that all the generic classe names are camelCase
- Make sure your PR stays focused on a single feature or category.
- Don't change project configs or any files unrelated to the subject you're working.
- Don't reformat code you don't modify.
- To format code use If you can 4DPop Beautifier macro.