50 lines
		
	
	
		
			1.9 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
		
		
			
		
	
	
			50 lines
		
	
	
		
			1.9 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| 
								 | 
							
								# How to contribute
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								## Resources in the documentation
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								* [Development quickstart](http://asciimoo.github.io/searx/dev/contribution_guide.html)
							 | 
						||
| 
								 | 
							
								* [Contribution guide](http://asciimoo.github.io/searx/dev/contribution_guide.html)
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								## Submitting PRs
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Please follow the provided PR template when writing a description for your changes.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Do not take criticism personally. When you get feedback, it is about your work,
							 | 
						||
| 
								 | 
							
								not your character, personality, etc. Keep in mind we all want to make the project better.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								When something is not clear, please ask questions to clear things up.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								If you would like to introduce a big architectural changes or do a refactoring
							 | 
						||
| 
								 | 
							
								either in the codebase or the development tools, please open an issue with a proposal
							 | 
						||
| 
								 | 
							
								first. This way we can think together about the problem and probably come up
							 | 
						||
| 
								 | 
							
								with a better solution.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								## Coding conventions and guidelines
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								### Commit messages
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								* Always write descriptive commit messages ("fix bug" is not acceptable).
							 | 
						||
| 
								 | 
							
								* Use the present tense ("Add feature" not "Added feature").
							 | 
						||
| 
								 | 
							
								* Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
							 | 
						||
| 
								 | 
							
								* Limit the first line to 72 characters or less.
							 | 
						||
| 
								 | 
							
								* Include the number of the issue you are fixing.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								### Coding guidelines
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								As a Python project, we must follow [PEP 8](https://www.python.org/dev/peps/pep-0008/) and [PEP 20](https://www.python.org/dev/peps/pep-0020/) guidelines.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Furthermore, follow the Clean code conventions. The most important
							 | 
						||
| 
								 | 
							
								in this project are the following rules:
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								* Simpler is better. [KISS principle](https://en.wikipedia.org/wiki/KISS_principle)
							 | 
						||
| 
								 | 
							
								* Be consistent.
							 | 
						||
| 
								 | 
							
								* Every function must do one thing.
							 | 
						||
| 
								 | 
							
								* Use descriptive names for functions and variables.
							 | 
						||
| 
								 | 
							
								* Always look for the root cause.
							 | 
						||
| 
								 | 
							
								* Keep configurable data high level.
							 | 
						||
| 
								 | 
							
								* Avoid negative conditionals.
							 | 
						||
| 
								 | 
							
								* Prefer fewer arguments.
							 | 
						||
| 
								 | 
							
								* Do not add obvious comment to code.
							 | 
						||
| 
								 | 
							
								* Do not comment out code, just delete lines.
							 | 
						||
| 
								 | 
							
								
							 |