Accessing Object properties
When accessing Object properties like 'Account.Name' multiple times throughout the code, is it better to create a variable and assign the property value to the variable once or is it fine to continuously reference the same property throughout the code? See example for more detail:
if(Account.Name.equals('Ben'))
Account.Status = 'Open';
else if(Account.Name.equals('Sim'))
Account.Status = 'Closed';
Case.Name = Account.Name;
Opportunity.Newest = Account.Name;
As you can see above, the same 'Account.Name' property is accessed multiple times. Is it more efficient to do something like:
String accountName = Account.Name;
if(accountName.equals('Ben'))
Account.Status = 'Open';
else if(accountName.equals('Sim'))
Account.Status = 'Closed';
Case.Name = accountName;
Opportunity.Newest = accountName;
apex code
New contributor
add a comment |
When accessing Object properties like 'Account.Name' multiple times throughout the code, is it better to create a variable and assign the property value to the variable once or is it fine to continuously reference the same property throughout the code? See example for more detail:
if(Account.Name.equals('Ben'))
Account.Status = 'Open';
else if(Account.Name.equals('Sim'))
Account.Status = 'Closed';
Case.Name = Account.Name;
Opportunity.Newest = Account.Name;
As you can see above, the same 'Account.Name' property is accessed multiple times. Is it more efficient to do something like:
String accountName = Account.Name;
if(accountName.equals('Ben'))
Account.Status = 'Open';
else if(accountName.equals('Sim'))
Account.Status = 'Closed';
Case.Name = accountName;
Opportunity.Newest = accountName;
apex code
New contributor
I do not see a reason to be more efficient to create a variable. Thinking, could be less, as you are creating more one variable.
– m Peixoto
Dec 21 at 10:08
add a comment |
When accessing Object properties like 'Account.Name' multiple times throughout the code, is it better to create a variable and assign the property value to the variable once or is it fine to continuously reference the same property throughout the code? See example for more detail:
if(Account.Name.equals('Ben'))
Account.Status = 'Open';
else if(Account.Name.equals('Sim'))
Account.Status = 'Closed';
Case.Name = Account.Name;
Opportunity.Newest = Account.Name;
As you can see above, the same 'Account.Name' property is accessed multiple times. Is it more efficient to do something like:
String accountName = Account.Name;
if(accountName.equals('Ben'))
Account.Status = 'Open';
else if(accountName.equals('Sim'))
Account.Status = 'Closed';
Case.Name = accountName;
Opportunity.Newest = accountName;
apex code
New contributor
When accessing Object properties like 'Account.Name' multiple times throughout the code, is it better to create a variable and assign the property value to the variable once or is it fine to continuously reference the same property throughout the code? See example for more detail:
if(Account.Name.equals('Ben'))
Account.Status = 'Open';
else if(Account.Name.equals('Sim'))
Account.Status = 'Closed';
Case.Name = Account.Name;
Opportunity.Newest = Account.Name;
As you can see above, the same 'Account.Name' property is accessed multiple times. Is it more efficient to do something like:
String accountName = Account.Name;
if(accountName.equals('Ben'))
Account.Status = 'Open';
else if(accountName.equals('Sim'))
Account.Status = 'Closed';
Case.Name = accountName;
Opportunity.Newest = accountName;
apex code
apex code
New contributor
New contributor
New contributor
asked Dec 21 at 9:47
Ash
161
161
New contributor
New contributor
I do not see a reason to be more efficient to create a variable. Thinking, could be less, as you are creating more one variable.
– m Peixoto
Dec 21 at 10:08
add a comment |
I do not see a reason to be more efficient to create a variable. Thinking, could be less, as you are creating more one variable.
– m Peixoto
Dec 21 at 10:08
I do not see a reason to be more efficient to create a variable. Thinking, could be less, as you are creating more one variable.
– m Peixoto
Dec 21 at 10:08
I do not see a reason to be more efficient to create a variable. Thinking, could be less, as you are creating more one variable.
– m Peixoto
Dec 21 at 10:08
add a comment |
2 Answers
2
active
oldest
votes
It is (or, at least, used to be) faster to use a variable if you're going to use the field lots of times. See this video for lots of experimentation:
https://www.youtube.com/watch?v=w6QnalRWlEE
Measured time on Salesforce will change as the compiler changes, and server load changes. So, unless you measure carefully, you might not even be able to see the difference.
Warning: opinion coming...
I would always treat code cleanliness (is it easy to read?) as more important than performance until you run into an actual performance problem. To quote Knuth:
Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these
attempts at efficiency actually have a strong negative impact when
debugging and maintenance are considered. We should forget about small
efficiencies, say about 97% of the time: premature optimization is the
root of all evil. Yet we should not pass up our opportunities in that
critical 3%.
However, introducing an extra variable can help with cleanliness because it gives you a chance to give that variable a descriptive name which makes the code easier to follow.
Personally, that's why I'd use the extra variable.
+1 While caching a field value is rarely worth it from a performance perspective, developers should be mindful of other types of variables. For example, if you get a value from a map and you plan on using it a lot, you can save significant CPU time. In all other cases, it's more of a legibility issue.
– sfdcfox
Dec 21 at 16:13
add a comment |
There could be minor efficiency improvement, but IMO more of coding cleaness as Aidan mentioned already.
This is what I will code below. If more conditions are coming, a switch statement
might fit better, or using base class and inherited class for polymorphism to scape from condition check.
String accountName = Account.Name;
if(accountName == 'Ben'){
Account.Status = 'Open';
} else if(accountName == 'Sim'){
Account.Status = 'Closed';
}
Case.Name = accountName;
Opportunity.Newest = accountName;
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Ash is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f244413%2faccessing-object-properties%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It is (or, at least, used to be) faster to use a variable if you're going to use the field lots of times. See this video for lots of experimentation:
https://www.youtube.com/watch?v=w6QnalRWlEE
Measured time on Salesforce will change as the compiler changes, and server load changes. So, unless you measure carefully, you might not even be able to see the difference.
Warning: opinion coming...
I would always treat code cleanliness (is it easy to read?) as more important than performance until you run into an actual performance problem. To quote Knuth:
Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these
attempts at efficiency actually have a strong negative impact when
debugging and maintenance are considered. We should forget about small
efficiencies, say about 97% of the time: premature optimization is the
root of all evil. Yet we should not pass up our opportunities in that
critical 3%.
However, introducing an extra variable can help with cleanliness because it gives you a chance to give that variable a descriptive name which makes the code easier to follow.
Personally, that's why I'd use the extra variable.
+1 While caching a field value is rarely worth it from a performance perspective, developers should be mindful of other types of variables. For example, if you get a value from a map and you plan on using it a lot, you can save significant CPU time. In all other cases, it's more of a legibility issue.
– sfdcfox
Dec 21 at 16:13
add a comment |
It is (or, at least, used to be) faster to use a variable if you're going to use the field lots of times. See this video for lots of experimentation:
https://www.youtube.com/watch?v=w6QnalRWlEE
Measured time on Salesforce will change as the compiler changes, and server load changes. So, unless you measure carefully, you might not even be able to see the difference.
Warning: opinion coming...
I would always treat code cleanliness (is it easy to read?) as more important than performance until you run into an actual performance problem. To quote Knuth:
Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these
attempts at efficiency actually have a strong negative impact when
debugging and maintenance are considered. We should forget about small
efficiencies, say about 97% of the time: premature optimization is the
root of all evil. Yet we should not pass up our opportunities in that
critical 3%.
However, introducing an extra variable can help with cleanliness because it gives you a chance to give that variable a descriptive name which makes the code easier to follow.
Personally, that's why I'd use the extra variable.
+1 While caching a field value is rarely worth it from a performance perspective, developers should be mindful of other types of variables. For example, if you get a value from a map and you plan on using it a lot, you can save significant CPU time. In all other cases, it's more of a legibility issue.
– sfdcfox
Dec 21 at 16:13
add a comment |
It is (or, at least, used to be) faster to use a variable if you're going to use the field lots of times. See this video for lots of experimentation:
https://www.youtube.com/watch?v=w6QnalRWlEE
Measured time on Salesforce will change as the compiler changes, and server load changes. So, unless you measure carefully, you might not even be able to see the difference.
Warning: opinion coming...
I would always treat code cleanliness (is it easy to read?) as more important than performance until you run into an actual performance problem. To quote Knuth:
Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these
attempts at efficiency actually have a strong negative impact when
debugging and maintenance are considered. We should forget about small
efficiencies, say about 97% of the time: premature optimization is the
root of all evil. Yet we should not pass up our opportunities in that
critical 3%.
However, introducing an extra variable can help with cleanliness because it gives you a chance to give that variable a descriptive name which makes the code easier to follow.
Personally, that's why I'd use the extra variable.
It is (or, at least, used to be) faster to use a variable if you're going to use the field lots of times. See this video for lots of experimentation:
https://www.youtube.com/watch?v=w6QnalRWlEE
Measured time on Salesforce will change as the compiler changes, and server load changes. So, unless you measure carefully, you might not even be able to see the difference.
Warning: opinion coming...
I would always treat code cleanliness (is it easy to read?) as more important than performance until you run into an actual performance problem. To quote Knuth:
Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these
attempts at efficiency actually have a strong negative impact when
debugging and maintenance are considered. We should forget about small
efficiencies, say about 97% of the time: premature optimization is the
root of all evil. Yet we should not pass up our opportunities in that
critical 3%.
However, introducing an extra variable can help with cleanliness because it gives you a chance to give that variable a descriptive name which makes the code easier to follow.
Personally, that's why I'd use the extra variable.
edited Dec 21 at 16:27
answered Dec 21 at 10:42
Aidan
6,785942
6,785942
+1 While caching a field value is rarely worth it from a performance perspective, developers should be mindful of other types of variables. For example, if you get a value from a map and you plan on using it a lot, you can save significant CPU time. In all other cases, it's more of a legibility issue.
– sfdcfox
Dec 21 at 16:13
add a comment |
+1 While caching a field value is rarely worth it from a performance perspective, developers should be mindful of other types of variables. For example, if you get a value from a map and you plan on using it a lot, you can save significant CPU time. In all other cases, it's more of a legibility issue.
– sfdcfox
Dec 21 at 16:13
+1 While caching a field value is rarely worth it from a performance perspective, developers should be mindful of other types of variables. For example, if you get a value from a map and you plan on using it a lot, you can save significant CPU time. In all other cases, it's more of a legibility issue.
– sfdcfox
Dec 21 at 16:13
+1 While caching a field value is rarely worth it from a performance perspective, developers should be mindful of other types of variables. For example, if you get a value from a map and you plan on using it a lot, you can save significant CPU time. In all other cases, it's more of a legibility issue.
– sfdcfox
Dec 21 at 16:13
add a comment |
There could be minor efficiency improvement, but IMO more of coding cleaness as Aidan mentioned already.
This is what I will code below. If more conditions are coming, a switch statement
might fit better, or using base class and inherited class for polymorphism to scape from condition check.
String accountName = Account.Name;
if(accountName == 'Ben'){
Account.Status = 'Open';
} else if(accountName == 'Sim'){
Account.Status = 'Closed';
}
Case.Name = accountName;
Opportunity.Newest = accountName;
add a comment |
There could be minor efficiency improvement, but IMO more of coding cleaness as Aidan mentioned already.
This is what I will code below. If more conditions are coming, a switch statement
might fit better, or using base class and inherited class for polymorphism to scape from condition check.
String accountName = Account.Name;
if(accountName == 'Ben'){
Account.Status = 'Open';
} else if(accountName == 'Sim'){
Account.Status = 'Closed';
}
Case.Name = accountName;
Opportunity.Newest = accountName;
add a comment |
There could be minor efficiency improvement, but IMO more of coding cleaness as Aidan mentioned already.
This is what I will code below. If more conditions are coming, a switch statement
might fit better, or using base class and inherited class for polymorphism to scape from condition check.
String accountName = Account.Name;
if(accountName == 'Ben'){
Account.Status = 'Open';
} else if(accountName == 'Sim'){
Account.Status = 'Closed';
}
Case.Name = accountName;
Opportunity.Newest = accountName;
There could be minor efficiency improvement, but IMO more of coding cleaness as Aidan mentioned already.
This is what I will code below. If more conditions are coming, a switch statement
might fit better, or using base class and inherited class for polymorphism to scape from condition check.
String accountName = Account.Name;
if(accountName == 'Ben'){
Account.Status = 'Open';
} else if(accountName == 'Sim'){
Account.Status = 'Closed';
}
Case.Name = accountName;
Opportunity.Newest = accountName;
answered Dec 21 at 11:23
Xi Xiao
857
857
add a comment |
add a comment |
Ash is a new contributor. Be nice, and check out our Code of Conduct.
Ash is a new contributor. Be nice, and check out our Code of Conduct.
Ash is a new contributor. Be nice, and check out our Code of Conduct.
Ash is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f244413%2faccessing-object-properties%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I do not see a reason to be more efficient to create a variable. Thinking, could be less, as you are creating more one variable.
– m Peixoto
Dec 21 at 10:08