Skip to content

Latest commit

 

History

History
95 lines (77 loc) · 4.96 KB

CONTRIBUTING.md

File metadata and controls

95 lines (77 loc) · 4.96 KB

Contributing

👍 Thanks for considering to contribute to the project, we appreciate it. 👍

Outline

Code of Conduct.

Before starting the rest of the process, please take time read and understand the contributing Code of Conduct.

Spread the Word

Another way to contribute is to write about Jet and the NextGen Project, or speak about Jet on some online forums to encourage a friendly discussion. The language is at its early stages, so we want as much exposure as possible. We have currently have a channel on the Programming Language Discord Server where we discuss new changes and possible integrations with new technologies.

Add your own Features

Want to add amazing language features yourself? Submit your own language syntax ideas here and if selected, the syntax/feature will be named after you! (or an appropriate name of your choosing).

Note: Existing Language Features/Syntax suggested will not be named after you. We love suggestions of new features of the language, but please be mindful to see if your suggestion has been already been accepted or an existing or planned language feature.

Style Guidelines

All programs under the NextGen Project follow the following C++ Style Guidlines.

  • Getter and Setter functions are to be named using camelCase
  • Functions (including in namespaces and in classes) should be denoted with MyFunction notation
  • Class and Struct member variables should be deonoted with MyVariable
  • Don't be too generous with your comments. Use them appropriately, especially when describing a complicated task
  • Preprocessors have a \t between the '#'. For example: # include <iostream>. This is done to be consistant with config
  • Lines should be no longer than 80 characters. We like to limit this line length for readibility
  • Mark implicit constructors with /*implicit*/ indication
  • Class and Struct names in-general should be denoted with MyClass notation unless we follow specific format guidlines with a library
  • Use the // STD NAMING convention appropriately. This means that we are to use only snake_case when naming items in that scope, for example, a class with that name requires all its methods and variables to be denoted as snake_case.

When writing nested namespace use the following setup to be consistent with other files:

namespace A { namespace B { namespace C
{
    // ...
}}}

Note: There are a few exceptions to the rules above: If we create an STL-like object, keep styling based on STL styling, and just make sure to use common sense. If something has a very long typename and has better readibility using trailing return type, use it, prioritize readibility over anything else.

Committing Guidelines

All commits to the project's repository are follow the following Guidelines.

  • Please limit your commit messages to no more than 10 words
  • Start all of your commit messages with a capital letter after the designated icon (see below)
  • Don't end your commiting messages with .
  • Please use the following icons before your commit message to indicate changes made:
    • 🎨 :art: when improving the format/structure of the code
    • ➕ :heavy_plus_sign: when adding new features to existing code
    • ⚡ :zap: when improving performance
    • 📖 :book: when writing docs
    • 🐧 :penguin: when updating portability
    • 🐛 :bug: when fixing a bug
    • 🔥 :fire: when source files are moved, changed, or deleted
    • 🔧 :wrench: when fixing build system (CMake, CI)
    • ✅ :white_check_mark: when working on tests

Pull Requests

Pull Requests are pretty straightforward. You have a change to the existing source code, great :), now you want create a pull request directly. If workflow succeeds and code is checked by the team, then you are ready to merge into the branch you requested for.

Licensing

As a contributor, any changes you contribute are to be done under the terms of the project's license, unless otherwise specified.