Coding Standards and Languages Supported - saayam-for-all/docs GitHub Wiki
Yes, we have a very complicated software architecture. It's NOT easy to design a highly available and highly scalable application. Unless we follow strict coding standards to write quality code, it would be a nightmare to maintain this massively large application.
This is an open source project. Many volunteers come and build a component or write a few lines of code and leave the org. We want to maintain the code quality by having a very strict code pipelines or CI/CD process.
We divided major functionality into multiple micro services. Each micro service team can independently choose the language of their choice, follow its coding standards and make the deliverable available in their repo.
Here are some suggested guidelines:
- Read Code Complete 2 book
- Git commands - cheat sheet, commands, branching
- How to name buttons in our UI
- Choose good names for the file names, method names, variable names etc. These names have to be intuitive and should NOT be less then 3 or 4 letter length. For e.g. a variable should NOT be a, b or c unless it is very short lived. Instead, it is better to use a proper small word like name, age, myName etc.
- Some languages like Java insist on a particular standard for names - myVar, MyClass, myMethod etc.
- All your functionality has to be unit tested. We expect a minimum of 90% code coverage.
- Each code transaction has to be approved by two senior coders. The more we do code review that is better for us. Feedback has to be constructive. Seniors have to mentor juniors so that juniors get trained well in good coding practices.
Which branch to use?
All our repos will have three standard branches: main, dev and test.
You need to start new development from the dev branch. Once after doing your development, you need to sync with the "test" branch, do a quick testing from the test branch. There are NO merge approvals needed for merging your changes into the test branch. Absolutely there is NO bureaucracy :) Once your changes are good, you need to start unit test cases and make sure that you would get at least 90% code coverage numbers.
Then you sync your code with the "dev" branch. Raise a PR to get a minimum of TWO approvals. You should NOT be merging any code with OUT two approvals and with OUT having 90% code coverage.
Code from the "dev" branch is selectively moved to the "main" branch ONLY by the leads. This will be further tested before moving it to our product in AWS S3 area. We use private buckets in Virginia region S3. Archives in the form of Jar, Zip or Docker images only should be in these private folders.
As an exception, only the Web app code will go to the public buckets of the Virginia region S3.
Code Style and Formatting
Webapp and Mobile app projects
- Indentation style: space
- Indentation size: 2
- Remove trailing spaces
- Spaces within ES6 import braces
Languages Supported
Our application is multilingual. We are supporting the ten most popular languages. For choosing supported languages we used a table, shown in the List of languages by total number of speakers page on Wikipedia.
Note, that in this step we don't support right to left languages like Arabic and Hebrew. The reason is that supporting right to left languages will require CSS changing in all our pages. We will need to implement the CSS property called direction.
| Language | Locale | Total speakers |
|---|---|---|
| English | en_US | 1.515 billion |
| Mandarin Chinese | zh-CN | 1.140 billion |
| Hindi | hi_IN | 609 million |
| Spanish | es-ES | 560 million |
| French | fr-FR | 312 million |
| Bengali | bn-BD | 278 million |
| Portuguese | pt-PT | 264 million |
| Russian | ru-RU | 255 million |
| German | de-DE | 134 million |
| Telugu | te-IN | 96 million |