-1

This question already has an answer here:

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?

marked as duplicate by gnat, Bart van Ingen Schenau, amon, user22815, Erik Eidt Jan 21 '17 at 1:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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
  • 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
  • 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
  • 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 amazon.de/Deadline-Novel-About-Project-Management/dp/0932633390 since it will give you lots of insight and fun at the same time. – qwerty_so Dec 28 '16 at 0:05
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.

  • 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

Not the answer you're looking for? Browse other questions tagged or ask your own question.