Accessing Object properties












3














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;









share|improve this question







New contributor




Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • 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
















3














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;









share|improve this question







New contributor




Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • 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














3












3








3







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;









share|improve this question







New contributor




Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question







New contributor




Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Dec 21 at 9:47









Ash

161




161




New contributor




Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Ash is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • 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




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










2 Answers
2






active

oldest

votes


















5














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.






share|improve this answer























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



















0














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;





share|improve this answer





















    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.










    draft saved

    draft discarded


















    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









    5














    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.






    share|improve this answer























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
















    5














    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.






    share|improve this answer























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














    5












    5








    5






    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.






    share|improve this answer














    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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


















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













    0














    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;





    share|improve this answer


























      0














      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;





      share|improve this answer
























        0












        0








        0






        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;





        share|improve this answer












        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;






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 21 at 11:23









        Xi Xiao

        857




        857






















            Ash is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            數位音樂下載

            When can things happen in Etherscan, such as the picture below?

            格利澤436b