Does it ever make sense for a refactor to end up with a higher LOC?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












Are there cases where more verbose code (as in more logical statements) is more clean than more concise code?










share|improve this question







New contributor




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



















  • see Why do 'some examples' and 'list of things' questions get closed? (also, Hint: Software Engineering Stack Exchange... expect research before asking)
    – gnat
    1 hour ago







  • 5




    Of course it does. Even when eliminating duplication, the code to define the new extracted function takes up space of its own. Writing a new function may take four lines and save only two, and still be a worthwhile thing to do.
    – Kilian Foth
    1 hour ago















up vote
1
down vote

favorite












Are there cases where more verbose code (as in more logical statements) is more clean than more concise code?










share|improve this question







New contributor




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



















  • see Why do 'some examples' and 'list of things' questions get closed? (also, Hint: Software Engineering Stack Exchange... expect research before asking)
    – gnat
    1 hour ago







  • 5




    Of course it does. Even when eliminating duplication, the code to define the new extracted function takes up space of its own. Writing a new function may take four lines and save only two, and still be a worthwhile thing to do.
    – Kilian Foth
    1 hour ago













up vote
1
down vote

favorite









up vote
1
down vote

favorite











Are there cases where more verbose code (as in more logical statements) is more clean than more concise code?










share|improve this question







New contributor




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











Are there cases where more verbose code (as in more logical statements) is more clean than more concise code?







refactoring






share|improve this question







New contributor




wrongusername 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




wrongusername 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




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









asked 2 hours ago









wrongusername

1122




1122




New contributor




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





New contributor





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






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











  • see Why do 'some examples' and 'list of things' questions get closed? (also, Hint: Software Engineering Stack Exchange... expect research before asking)
    – gnat
    1 hour ago







  • 5




    Of course it does. Even when eliminating duplication, the code to define the new extracted function takes up space of its own. Writing a new function may take four lines and save only two, and still be a worthwhile thing to do.
    – Kilian Foth
    1 hour ago

















  • see Why do 'some examples' and 'list of things' questions get closed? (also, Hint: Software Engineering Stack Exchange... expect research before asking)
    – gnat
    1 hour ago







  • 5




    Of course it does. Even when eliminating duplication, the code to define the new extracted function takes up space of its own. Writing a new function may take four lines and save only two, and still be a worthwhile thing to do.
    – Kilian Foth
    1 hour ago
















see Why do 'some examples' and 'list of things' questions get closed? (also, Hint: Software Engineering Stack Exchange... expect research before asking)
– gnat
1 hour ago





see Why do 'some examples' and 'list of things' questions get closed? (also, Hint: Software Engineering Stack Exchange... expect research before asking)
– gnat
1 hour ago





5




5




Of course it does. Even when eliminating duplication, the code to define the new extracted function takes up space of its own. Writing a new function may take four lines and save only two, and still be a worthwhile thing to do.
– Kilian Foth
1 hour ago





Of course it does. Even when eliminating duplication, the code to define the new extracted function takes up space of its own. Writing a new function may take four lines and save only two, and still be a worthwhile thing to do.
– Kilian Foth
1 hour ago











2 Answers
2






active

oldest

votes

















up vote
5
down vote













To answer that, let's take a real world example that happened to me. In C# a library that I maintain, I had the following code:



TResult IConsFuncMatcher<T, TResult>.Result() =>
TryCons(_enumerator) is var simpleMatchData && !simpleMatchData.head.HasValue
? _emptyValue.supplied
? _emptyValue.value
: throw new NoMatchException("No empty clause supplied");
: _recursiveConsTests.Any()
? CalculateRecursiveResult()
: CalculateSimpleResult(simpleMatchData);


Discussing this with peers, the unanimous verdict was that the nested ternary expressions, coupled with the "clever" use of is var resulted in terse, but difficult to read code.



So I refactored it to:



TResult IConsFuncMatcher<T, TResult>.Result()

var simpleMatchData = TryCons(_enumerator);

if (!simpleMatchData.head.HasValue)

return _emptyValue.supplied
? _emptyValue.value
: throw new NoMatchException("No empty clause supplied");


return _recursiveConsTests.Any()
? CalculateRecursiveResult()
: CalculateSimpleResult(simpleMatchData);



The original version contained just one compound expression with an implicit return. The new version now contains an explicit variable declaration, an if statement and two explicit returns. It contains more statements and more lines of code. Yet everyone I consulted considered it easier to read and reason, which are key aspects of "clean code".



So the answer to your question is an emphatic "yes", more verbose can be cleaner than concise code and is thus a valid refactoring.






share|improve this answer



























    up vote
    2
    down vote













    1. Lack of correlation between LOC and readability.



    The goal of refactoring is to improve the readability of a piece of code.



    LOC is a very basic metric which, sometimes, correlates with the readability of a piece of code: for instance, a method with a few thousands of LOC is likely to be unreadable. It should be noted, however, that LOC is not the only metric, and in many cases lacks the correlation with the readability. For instance, a 6 LOC method is not necessarily more readable than a 4 LOC method.



    2. Some refactoring techniques consist of adding LOCs.



    If you take a list of refactoring techniques, you can easily spot the ones which consist in intentionnally adding LOCs. Examples:




    • Replace Magic Number with Symbolic Constant.


    • Extract Variable.

    Both are very useful refactoring techniques, and their effect on the LOC is completely irrelevant when considering whether to use them or not.



    Conclusion:



    LOC is a dangerous metric. It is very easy to measure, and is very difficult to interpret correctly.



    Until you become familiar with the techniques of measurement of code quality, consider avoiding even measuring LOC in the first place. Most of the time, you won't get anything relevant, and there would be cases where it will mislead you into decreasing the quality of your code.






    share|improve this answer




















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "131"
      ;
      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',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );






      wrongusername 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%2fsoftwareengineering.stackexchange.com%2fquestions%2f379879%2fdoes-it-ever-make-sense-for-a-refactor-to-end-up-with-a-higher-loc%23new-answer', 'question_page');

      );

      Post as a guest






























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      5
      down vote













      To answer that, let's take a real world example that happened to me. In C# a library that I maintain, I had the following code:



      TResult IConsFuncMatcher<T, TResult>.Result() =>
      TryCons(_enumerator) is var simpleMatchData && !simpleMatchData.head.HasValue
      ? _emptyValue.supplied
      ? _emptyValue.value
      : throw new NoMatchException("No empty clause supplied");
      : _recursiveConsTests.Any()
      ? CalculateRecursiveResult()
      : CalculateSimpleResult(simpleMatchData);


      Discussing this with peers, the unanimous verdict was that the nested ternary expressions, coupled with the "clever" use of is var resulted in terse, but difficult to read code.



      So I refactored it to:



      TResult IConsFuncMatcher<T, TResult>.Result()

      var simpleMatchData = TryCons(_enumerator);

      if (!simpleMatchData.head.HasValue)

      return _emptyValue.supplied
      ? _emptyValue.value
      : throw new NoMatchException("No empty clause supplied");


      return _recursiveConsTests.Any()
      ? CalculateRecursiveResult()
      : CalculateSimpleResult(simpleMatchData);



      The original version contained just one compound expression with an implicit return. The new version now contains an explicit variable declaration, an if statement and two explicit returns. It contains more statements and more lines of code. Yet everyone I consulted considered it easier to read and reason, which are key aspects of "clean code".



      So the answer to your question is an emphatic "yes", more verbose can be cleaner than concise code and is thus a valid refactoring.






      share|improve this answer
























        up vote
        5
        down vote













        To answer that, let's take a real world example that happened to me. In C# a library that I maintain, I had the following code:



        TResult IConsFuncMatcher<T, TResult>.Result() =>
        TryCons(_enumerator) is var simpleMatchData && !simpleMatchData.head.HasValue
        ? _emptyValue.supplied
        ? _emptyValue.value
        : throw new NoMatchException("No empty clause supplied");
        : _recursiveConsTests.Any()
        ? CalculateRecursiveResult()
        : CalculateSimpleResult(simpleMatchData);


        Discussing this with peers, the unanimous verdict was that the nested ternary expressions, coupled with the "clever" use of is var resulted in terse, but difficult to read code.



        So I refactored it to:



        TResult IConsFuncMatcher<T, TResult>.Result()

        var simpleMatchData = TryCons(_enumerator);

        if (!simpleMatchData.head.HasValue)

        return _emptyValue.supplied
        ? _emptyValue.value
        : throw new NoMatchException("No empty clause supplied");


        return _recursiveConsTests.Any()
        ? CalculateRecursiveResult()
        : CalculateSimpleResult(simpleMatchData);



        The original version contained just one compound expression with an implicit return. The new version now contains an explicit variable declaration, an if statement and two explicit returns. It contains more statements and more lines of code. Yet everyone I consulted considered it easier to read and reason, which are key aspects of "clean code".



        So the answer to your question is an emphatic "yes", more verbose can be cleaner than concise code and is thus a valid refactoring.






        share|improve this answer






















          up vote
          5
          down vote










          up vote
          5
          down vote









          To answer that, let's take a real world example that happened to me. In C# a library that I maintain, I had the following code:



          TResult IConsFuncMatcher<T, TResult>.Result() =>
          TryCons(_enumerator) is var simpleMatchData && !simpleMatchData.head.HasValue
          ? _emptyValue.supplied
          ? _emptyValue.value
          : throw new NoMatchException("No empty clause supplied");
          : _recursiveConsTests.Any()
          ? CalculateRecursiveResult()
          : CalculateSimpleResult(simpleMatchData);


          Discussing this with peers, the unanimous verdict was that the nested ternary expressions, coupled with the "clever" use of is var resulted in terse, but difficult to read code.



          So I refactored it to:



          TResult IConsFuncMatcher<T, TResult>.Result()

          var simpleMatchData = TryCons(_enumerator);

          if (!simpleMatchData.head.HasValue)

          return _emptyValue.supplied
          ? _emptyValue.value
          : throw new NoMatchException("No empty clause supplied");


          return _recursiveConsTests.Any()
          ? CalculateRecursiveResult()
          : CalculateSimpleResult(simpleMatchData);



          The original version contained just one compound expression with an implicit return. The new version now contains an explicit variable declaration, an if statement and two explicit returns. It contains more statements and more lines of code. Yet everyone I consulted considered it easier to read and reason, which are key aspects of "clean code".



          So the answer to your question is an emphatic "yes", more verbose can be cleaner than concise code and is thus a valid refactoring.






          share|improve this answer












          To answer that, let's take a real world example that happened to me. In C# a library that I maintain, I had the following code:



          TResult IConsFuncMatcher<T, TResult>.Result() =>
          TryCons(_enumerator) is var simpleMatchData && !simpleMatchData.head.HasValue
          ? _emptyValue.supplied
          ? _emptyValue.value
          : throw new NoMatchException("No empty clause supplied");
          : _recursiveConsTests.Any()
          ? CalculateRecursiveResult()
          : CalculateSimpleResult(simpleMatchData);


          Discussing this with peers, the unanimous verdict was that the nested ternary expressions, coupled with the "clever" use of is var resulted in terse, but difficult to read code.



          So I refactored it to:



          TResult IConsFuncMatcher<T, TResult>.Result()

          var simpleMatchData = TryCons(_enumerator);

          if (!simpleMatchData.head.HasValue)

          return _emptyValue.supplied
          ? _emptyValue.value
          : throw new NoMatchException("No empty clause supplied");


          return _recursiveConsTests.Any()
          ? CalculateRecursiveResult()
          : CalculateSimpleResult(simpleMatchData);



          The original version contained just one compound expression with an implicit return. The new version now contains an explicit variable declaration, an if statement and two explicit returns. It contains more statements and more lines of code. Yet everyone I consulted considered it easier to read and reason, which are key aspects of "clean code".



          So the answer to your question is an emphatic "yes", more verbose can be cleaner than concise code and is thus a valid refactoring.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 46 mins ago









          David Arno

          25.6k64883




          25.6k64883






















              up vote
              2
              down vote













              1. Lack of correlation between LOC and readability.



              The goal of refactoring is to improve the readability of a piece of code.



              LOC is a very basic metric which, sometimes, correlates with the readability of a piece of code: for instance, a method with a few thousands of LOC is likely to be unreadable. It should be noted, however, that LOC is not the only metric, and in many cases lacks the correlation with the readability. For instance, a 6 LOC method is not necessarily more readable than a 4 LOC method.



              2. Some refactoring techniques consist of adding LOCs.



              If you take a list of refactoring techniques, you can easily spot the ones which consist in intentionnally adding LOCs. Examples:




              • Replace Magic Number with Symbolic Constant.


              • Extract Variable.

              Both are very useful refactoring techniques, and their effect on the LOC is completely irrelevant when considering whether to use them or not.



              Conclusion:



              LOC is a dangerous metric. It is very easy to measure, and is very difficult to interpret correctly.



              Until you become familiar with the techniques of measurement of code quality, consider avoiding even measuring LOC in the first place. Most of the time, you won't get anything relevant, and there would be cases where it will mislead you into decreasing the quality of your code.






              share|improve this answer
























                up vote
                2
                down vote













                1. Lack of correlation between LOC and readability.



                The goal of refactoring is to improve the readability of a piece of code.



                LOC is a very basic metric which, sometimes, correlates with the readability of a piece of code: for instance, a method with a few thousands of LOC is likely to be unreadable. It should be noted, however, that LOC is not the only metric, and in many cases lacks the correlation with the readability. For instance, a 6 LOC method is not necessarily more readable than a 4 LOC method.



                2. Some refactoring techniques consist of adding LOCs.



                If you take a list of refactoring techniques, you can easily spot the ones which consist in intentionnally adding LOCs. Examples:




                • Replace Magic Number with Symbolic Constant.


                • Extract Variable.

                Both are very useful refactoring techniques, and their effect on the LOC is completely irrelevant when considering whether to use them or not.



                Conclusion:



                LOC is a dangerous metric. It is very easy to measure, and is very difficult to interpret correctly.



                Until you become familiar with the techniques of measurement of code quality, consider avoiding even measuring LOC in the first place. Most of the time, you won't get anything relevant, and there would be cases where it will mislead you into decreasing the quality of your code.






                share|improve this answer






















                  up vote
                  2
                  down vote










                  up vote
                  2
                  down vote









                  1. Lack of correlation between LOC and readability.



                  The goal of refactoring is to improve the readability of a piece of code.



                  LOC is a very basic metric which, sometimes, correlates with the readability of a piece of code: for instance, a method with a few thousands of LOC is likely to be unreadable. It should be noted, however, that LOC is not the only metric, and in many cases lacks the correlation with the readability. For instance, a 6 LOC method is not necessarily more readable than a 4 LOC method.



                  2. Some refactoring techniques consist of adding LOCs.



                  If you take a list of refactoring techniques, you can easily spot the ones which consist in intentionnally adding LOCs. Examples:




                  • Replace Magic Number with Symbolic Constant.


                  • Extract Variable.

                  Both are very useful refactoring techniques, and their effect on the LOC is completely irrelevant when considering whether to use them or not.



                  Conclusion:



                  LOC is a dangerous metric. It is very easy to measure, and is very difficult to interpret correctly.



                  Until you become familiar with the techniques of measurement of code quality, consider avoiding even measuring LOC in the first place. Most of the time, you won't get anything relevant, and there would be cases where it will mislead you into decreasing the quality of your code.






                  share|improve this answer












                  1. Lack of correlation between LOC and readability.



                  The goal of refactoring is to improve the readability of a piece of code.



                  LOC is a very basic metric which, sometimes, correlates with the readability of a piece of code: for instance, a method with a few thousands of LOC is likely to be unreadable. It should be noted, however, that LOC is not the only metric, and in many cases lacks the correlation with the readability. For instance, a 6 LOC method is not necessarily more readable than a 4 LOC method.



                  2. Some refactoring techniques consist of adding LOCs.



                  If you take a list of refactoring techniques, you can easily spot the ones which consist in intentionnally adding LOCs. Examples:




                  • Replace Magic Number with Symbolic Constant.


                  • Extract Variable.

                  Both are very useful refactoring techniques, and their effect on the LOC is completely irrelevant when considering whether to use them or not.



                  Conclusion:



                  LOC is a dangerous metric. It is very easy to measure, and is very difficult to interpret correctly.



                  Until you become familiar with the techniques of measurement of code quality, consider avoiding even measuring LOC in the first place. Most of the time, you won't get anything relevant, and there would be cases where it will mislead you into decreasing the quality of your code.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 27 mins ago









                  Arseni Mourzenko

                  111k26273443




                  111k26273443




















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









                       

                      draft saved


                      draft discarded


















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












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











                      wrongusername 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%2fsoftwareengineering.stackexchange.com%2fquestions%2f379879%2fdoes-it-ever-make-sense-for-a-refactor-to-end-up-with-a-higher-loc%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Comments

                      Popular posts from this blog

                      What does second last employer means? [closed]

                      List of Gilmore Girls characters

                      One-line joke