+ Start a Discussion
chinni dchinni d 

Best Practices of Trigger?

Please try searching google before posting questions like this.  A simple search [1] returns tons of results.  Also, please try to expand upon your question using the body of the post instead of just the title.

[1] https://www.google.com/webhp?q=apex+trigger+best+practices
Amit Chaudhary 8Amit Chaudhary 8
I am totaly agree with pcon.

Please check below post. I hope that will help you

1) http://amitsalesforce.blogspot.in/2015/06/trigger-best-practices-sample-trigger.html

1) One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts

2) Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.

3) Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers

4) Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits

7) Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore

8) Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail
jyothsna reddy 5jyothsna reddy 5
Hi ,
1.Avoid writing DML,SOQL and @future methods in ‘for’ loop:
Queries or DML or @future methods are placed inside a for loop,database operations are invoked once per iteration of the loop making it is very easy to reach governer limits.
Instead, move any database operations outside of for loops. If you need to query, query once, retrieve all the necessary data in a single query, then iterate over the results. If you need to modify the data, batch up data into a list and invoke your DML once on that list of data.
2. avoid multiple triggers on the same object.
It is important to avoid the redundancies and ineffiencies when deploying multiple triggers on the same object. Developer independently ,it is possible to have redundent queries that query same dataset or possibly have redundent in ‘for’  statements.
One trigger getting the maximum of 100 queries,if we can write multiple triggers on the same object all triggers on the same object will share those 100 queries.
Multiple triggers on the same object is inefficient and redundencies exist.
Instead of writing multiple triggers on the same object we can write one trigger with multiple trigger context variables.

3.Avoid Hardcoding Ids
When deploying apex code between sandbox and production environments,or installing force.com Apexechange packages. It is essential to avoid hardcoding Ids in the Apex codeBy doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail.
4.Use Helper classes
Governor limits are calculated at runtime. After the request is initiated (Trigger, Visualforce page, etc.), any Apex code executed in that transaction applies and shares the governor limits. So if a trigger uses some Apex methods written in a helper class, it's important that those shared Apex methods are properly designed to handle bulk records. These methods should be written to be invoked with a set of records, especially if the method has a SOQL query or DML operation.
5.use of the limits apex methods to avoid hitting governor limits

Please check below link for more information. I hope that will help you