Development Guidelines

Introduction

The propose of this page is define the rules to development new features or maintenance of existing code of the SalesforceSharp.

General rules

• 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.

Documentation

• Every public code must be fully documented.
• Commentaries for complex blocks or not obvious (if it is too complex, review the code using SOLID).

Naming

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;

s_instancesCount.

For the rest we use the standard set by Microsoft: Naming Guidelines.

Testing

We should create Unit Tests and Functional Tests for every new feature. In some cases the Unit Tests are not possible because the SalesforceSharp depends directly from RestClient (RestSharp) [this is good point for refactoring, we could remove this directly dependency]. So, in some cases Unit Tests are not possible, but the 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: Exemplo:

• Create_ValidRecordWithAnonymous_Created
• Create_ValidRecordWithClassWithWrongProperties_Exception
• Update_InvalidId_Exception
• Authenticate_InvalidUsername_AuthenticationFailure