This style guide provides some general rules and recommendations for writing code and documentation for informatician. Please follow this guide as much as possible to ensure consistency and quality of your contributions.
You can use Prettier to format our code automatically. Please install Prettier in your editor or run it before committing your changes. You can also use npm run format
to format all the files in the project.
You can use ESLint to enforce some code style rules and catch common errors. Please install ESLint in your editor or run it before committing your changes. You can also use npm run lint
to check all the files in the project.
Some general code style rules are:
- Use 2 spaces for indentation
- Use single quotes for strings
- Use semicolons at the end of statements
- Use camelCase for variables and functions
- Use PascalCase for classes and components
- Use const and let instead of var
- Use arrow functions instead of function expressions
- Use template literals instead of string concatenation
- Use destructuring assignment instead of accessing properties
- Use spread operator instead of Object.assign or array methods
- Use async/await instead of callbacks or promises
- Use === and !== instead of == and !=
- Use descriptive and meaningful names for variables, functions, classes, and components
- Avoid using global variables or modifying built-in objects
- Avoid using magic numbers or hard-coded values
- Avoid using console.log or debugger statements
- Add comments to explain complex or unclear logic
- Document your code using JSDoc syntax
For more details and examples, see the Prettier and ESLint documentation.
We use Markdown to write our documentation. Please follow the Markdown style guide for general rules and recommendations on how to write Markdown files.
We also use some custom markup syntax for specific features on docs.github.com, such as alerts, tables, images, links, and more. Please see our markup reference guide for more details and examples on how to use these features.
Some general documentation style rules are:
- Use sentence case for headings and titles
- Use active voice instead of passive voice
- Use present tense instead of past or future tense
- Use simple and clear language
- Use short and concise sentences and paragraphs
- Use lists, tables, code blocks, images, and other visual aids to break up text and improve readability
- Use consistent terminology and avoid jargon or slang
- Use positive and polite tone and avoid negative or harsh words
- Use gender-neutral pronouns and avoid assumptions about the audience
- Provide examples and screenshots to illustrate concepts and procedures
- Provide links to relevant resources and references
- Provide feedback and contact information at the end of each document
For more details and examples, see the Microsoft Style Guide.
If you have any feedback or questions, please feel free to reach out to us at rohanshx@gmail.com or join our discussion forum
. We would love to hear from you!