-1

I want a feasible way to compare my project with my friend's project. I first thought it was enough to compare based on the number of code lines. But for some reason, people kept saying "LOC is not a good measure".

So, is the following method (I cooked up myself and I don't know if there is anything like this) good enough to compare my project with my friend's project?

We can calculate the effort_factor using the following algorithm:

effort_factor = 0
mini_method   = 0.01
proper_method = 1
min_avg_LOC_of_each_method = 6


for each_class in source_code:

    avg_LOC_of_each_method = LOC(each_class)/no_of_methods(each_class)

    for each_method in each_class:

        if avg_LOC_of_each_method < min_avg_LOC_of_each_method:
            avg_LOC_of_each_method = min_avg_LOC_of_each_method

        if LOC(each_method) < avg_LOC_of_each_method:
            effort_factor += mini_method
        else:
            effort_factor += proper_method

return effort_factor

Definitions for the symbols used here:

  • effort_factor: The measured amount of effort delivered by the developer (If the developer was maintaining an existing code, the absolute difference between the initially measured effort_factor and the final effort_factor must be the developer's contributed effort factor assuming he didn't reduce the functionality of the source-code by removing any existing features).
  • mini_method : The score-value (or weight) given to methods that contain less-than-average number of lines of code.
  • proper_method : The score-value (or weight) given to methods that contain more-than-average number of lines of code (these methods are assumed to be vital for the task carried over by the class).
  • min_avg_LOC_of_each_method : In cases where there are classes with no methods that exceed 6 lines of code, we must ensure that all the methods of the class are considered to be mini-methods (small methods). This constant that ensures that avg_LOC_of_each_method value never gets below 6.
  • avg_LOC_of_each_method : holds the number of lines of code per method in a class.
  • LOC() : computes the number of lines of code (for either a class or a method).

The basic idea of this method is to count the number of methods instead of the code-lines. Also we can assume, methods that have too less number of lines don't add much value to the code, as they can't solve any vital problems. At the same time methods with many lines of code can be assumed to solve a vital problem and hence can be given a greater weight-value.

Is this method feasible to measure and compare source codes? Or are there any flaws in it?

Sreram
  • 109
  • 6
  • 7
    What are you trying to measure, exactly? Yes, I know you've defined several metrics here, but what do you expect the results of those metrics to tell you? Measurements are useless without an actionable goal. You've put a lot of window dressing around your LOC measurement, but at the end of the day it still amounts to an LOC measurement, albeit a weighted one. You can put lipstick on a pig, but it's still a pig. – Robert Harvey Dec 27 '16 at 22:20
  • A measure to find the amount of effort required to code. For example, the measure must be proportional to the cost of developing the code. It is not possible to pay anyone based on the number of lines of code, as it will be more "expensive" though it has lesser functionality. So this must provide a universal way to measure the cost of code. – Sreram Dec 27 '16 at 22:30
  • Also, the algorithm does not measure the lines of code, it measures the number of methods. If there are two methods with 100 lines of code and 200 lines of code, it considers them both the same. A good developer must try his best to not include a whole 200 LOC in a single method, so this algorithm also scores based on basic coding style, to some degree. – Sreram Dec 27 '16 at 22:33
  • 1
    How do you adjust the cost measurement when, for example, I use a `foreach` loop requiring 20 or 30 lines of code instead of the 6-line Linq equivalent? Am I penalized for using a more expressive language that requires less lines of code to say the same thing? – Robert Harvey Dec 27 '16 at 22:33
  • Also, isn't this kind of [closing the barn door after the horse has bolted](http://www.nytimes.com/2008/01/23/opinion/23wed4.html)? Doesn't the code need to be already written for this to work, and if you track the time it takes to write it, do you even need this formula? – Robert Harvey Dec 27 '16 at 22:37
  • "Doesn't the code need to be already written for this to work" - actually no. Because, that 6 lines rule only applies when the value of `avg_LOC_of_each_method` gets less than 6. Under normal circumstances, the methods in a class are split in two parts: The one with more lines, and the one with less lines. We first compute the number of code lines per method in a class and use that as a dividing line. – Sreram Dec 27 '16 at 22:41
  • 1
    Sorry, but I don't get it. Methods require different amounts of effort to make them work, depending on what the goal is for each method, so I don't see how any measurement of lines of code or number of methods is going to yield any useful metric of effort. – Robert Harvey Dec 27 '16 at 22:43
  • So if the number of lines of code of a method is less than "number of code lines per method in a class" it classifies it as a "small method". Else it classifies it as a large method. – Sreram Dec 27 '16 at 22:44
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/50804/discussion-between-sreram-and-robert-harvey). – Sreram Dec 27 '16 at 22:44
  • see also: [What are useful metrics for source code?](http://softwareengineering.stackexchange.com/questions/27686/what-are-useful-metrics-for-source-code) – gnat Dec 27 '16 at 22:49
  • 3
    All attempts to measure anything using any of the metrics you suggest is so deeply flawed it becomes meaningless. Stop messing about trying to measure code, and start solving real world problems instead. – Kramii Dec 27 '16 at 22:49
  • 1
    Go and read https://www.amazon.de/Deadline-Novel-About-Project-Management/dp/0932633390 since it will give you lots of insight and fun at the same time. –  Dec 28 '16 at 00:05

1 Answers1

5

The basic idea of this method is to count the number of methods instead of the code-lines.

Well here's your problem.

The reason LOC counting doesn't work is because a programmer can spend days getting a one line regular expression just right or they can whip out a one line print statement in 2 seconds. If you pay them by loc they'll write a 5 page monster that does what the regex does.

Counting the number of methods has the same problem. How many ways do you really want to encourage me to implement toString()?

Code simply isn't something you can look at and decide how much effort has been put into it. You may be looking at something that's been revised 5 times that replaced 7 classes and took a week just to decouple from the framework we no longer use to say nothing of the whiteboard work and meetings that went into making these decisions.

So effort isn't something stored in the code. I doubt it's even in source control.

The only good metric I know for code isn't even about effort. It's about quality. Which is more important anyway. It's this:

enter image description here

The more interesting question:

I want a feasible way to compare my project with my friend's project.

When you compare your car with your buddies car you don't do it by looking under the hood. You do it on the track.

Ask your moms to use your programs to accomplish something and count the questions they ask before they finish.

Mom makes a great product tester.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • I get it now. I didn't think about "rewriting what is already there", I just thought about "copy-pasting code to fill space". – Sreram Dec 27 '16 at 23:08