-
Notifications
You must be signed in to change notification settings - Fork 61
Development Guidelines
The purpose of this page is define the rules to develop new features or maintenance of existing code in SalesforceSharp.
-
Follow the SOLID principles to design your code.
-
Keep the classes / methods with only one responsibility and dry. Class with more than 200 lines of code is already a warning sign. Methods with many lines probably indicate that there is more than one operation being performed in its scope.
-
No warnings in code.
- Public methods, classes and interfaces must be fully documented using XML documentation comments.
- Do not use "#pragma warning disable" to disable the warnings about public members documentation missing.
- Commentaries for complex blocks or not obvious (if it is too complex, review the code using SOLID).
-
For names of data members (private fields of classes), we use the notation for m_ instance members and s_ for static members. Example: m_context and s_instancesCount.
-
The right way to write is "Salesforce", not "SalesForce".
For the rest we use the standard set by Microsoft: Naming Guidelines.
We should create Unit Tests and Functional Tests for every new feature. In some cases the Unit Tests are not possible because SalesforceSharp depends directly upon RestClient (RestSharp) [this is good point for refactoring, we could remove this direct dependency]. So, in some cases Unit Tests are not possible, but functional tests are!
The name of test files should be the name of target class concatenated with the suffix "Test".
- Target class: SalesforceClient
- Test class: SalesforceClientTest
The name of the test methods should be follow the below structure: Example:
- Create_ValidRecordWithAnonymous_Created
- Create_ValidRecordWithClassWithWrongProperties_Exception
- Update_InvalidId_Exception
- Authenticate_InvalidUsername_AuthenticationFailure