Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
E
edx-platform
Overview
Overview
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
edx
edx-platform
Commits
f364e0ae
Commit
f364e0ae
authored
Jun 11, 2012
by
Piotr Mitros
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Documentation Standards
parent
c3480dae
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
15 additions
and
7 deletions
+15
-7
doc/code_standards.txt
+15
-7
No files found.
doc/code_standards.txt
View file @
f364e0ae
...
...
@@ -30,12 +30,12 @@ following standards:
1) Test Suite. Code must have reasonable, although not complete, test
coverage.
2) Consisten
cy
. Code must follow PEP8
2) Consisten
t
. Code must follow PEP8
3) Clean Abstractions.
4) Future
Compatibility
. Code must not be incompatible with the
4) Future
-Compatible
. Code must not be incompatible with the
long-term vision of either the codebase or of edX.
5) Properly Documented
6) Maintainab
ility/Deployability
6) Maintainab
le and deployable
7) Robust.
All code paths must be manually or automatically verified.
...
...
@@ -47,14 +47,15 @@ following standards:
1) Testable. We do not require test coverage, but we do require the
code to be structured such that it is possible to build tests.
2) Consisten
cy
. Code must follow PEP8
2) Consisten
t
. Code must follow PEP8
3) Clean abstractions or obvious throw-away code. One of the goals
of scaffolding is to define proper abstractions.
4) Future
Compatibility
. Code must not be incompatible with the
4) Future
-Compatible
. Code must not be incompatible with the
long-term vision of either the codebase or of edX.
5) Somewhat documented
6) Unpluggable. There should be a setting to disable scaffolding code
such that it is never run on production servers.
6) Unpluggable. There should be a setting to disable scaffolding code.
By default, and by policy, it should never be enabled on production
servers.
7) Purpose. The scaffolding must provide a clean reason for existence
(e.g. define a specific interface, etc.)
...
...
@@ -75,3 +76,10 @@ no hard standards.
* Each contributor is responsible for finding a person to review their
code. If it is not clear to the contributor who is appropriate, each
project has an owner
3. Documentation Standards
* Whenever possible, documentation should live in code.
* When impossible, it should live in the github repo.
* Discussion should live on github, Basecamp or Pivotal, depending on
context.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment