0

Having fewer lines of code per feature is typically better as it increases the developer productivity. Did anyone ever measure the number of code lines executions per line of code across multiple programming languages? I.e. each line of code is annotated with the number of executions of this line? Are there any statistics per programming language?

For example, I'm curious, if there are any language features that have an impact on the number of lines of code that are executed very rarely.

I'm mostly interested in significant difference per programming language. For sure: Within a project or within a function, there will always be some often executed lines and others are less often executed lines.

https://discourse.julialang.org/t/executed-lines-of-code-per-line-of-written-code/29017 is the closest I was able to find. Though, still a different metric.

Improve this question
20
  • 8
    "Having fewer lines of code per feature is typically better as it increases the developer productivity." Developer productivity cannot be usefully measured like that. Otherwise you could increase it in a snap simply by switching everything to COBOL. Commented Feb 21, 2024 at 13:55
  • 1
    What has "number of LOC per feature" to do with stats about how often a certain code line gets executed? Please clarify. Commented Feb 21, 2024 at 14:41
  • 1
    "Having fewer lines of code per feature is typically better as it increases the developer productivity." Tell that to anyone that's tried to read APL! Commented Feb 21, 2024 at 14:59
  • 1
    "Having fewer lines of code per feature is typically better as it increases the developer productivity." That kind of makes sense up to a point. You can waste a lot of time trying to reduce the number lines of code in a perfectly working solution (I've done this.) And while fewer lines of code can improve readability, extremely terse code can be harder to understand and maintain than a more 'fluffy' equivalent version. Commented Feb 21, 2024 at 15:19
  • 1
    I think if you watch the talk the "less lines of code" means developers getting more done by building on the work of others vs writing everything from scratch in assembly. ie If my language has list.Sort() vs me writing a sort function. In that sense yes productivity is greatly improved. Commented Feb 21, 2024 at 15:22

3 Answers 3

Reset to default
3

I'm curious, if there are any language features that have an impact on the number of lines of code that are executed very rarely.

Some languages are associated with source lines that are “hard to test” and execute seldom or even execute zero times during the Software Lifecycle.

Java’s throws keyword and the notion of “checked exceptions” leads to a great many lines of boilerplate source code. In many code bases the suite of automated tests never exercises those lines. Often one can prove that a Public API offers no way to reach a given exception handler, yet engineers author those SLOC because the compiler deems them syntactically necessary.

So yes, language features can strongly affect the measure you’re interested in.

Improve this answer
1
  • 1
    Great example! Interestingly, checked exceptions also can sometimes lead to a lot of unrelated seemingly changes when doing refactorizations. Commented Feb 22, 2024 at 14:32
5

I think in the linked talk "executed lines of code" means "executed processor instructions"

https://discourse.julialang.org/t/executed-lines-of-code-per-line-of-written-code/29017

Basically higher level languages do more with less typing.

Or in Jim Keller's words:

"You can write one line of code today and fire up a datacenter find a cat photo. If you tried to do that in assembly you would have 1000 people working for 1000 years... and they would fail."

If you imagine that line of code, it's going to be using libraries and the libraries will be using libraries. Javascript and python will be using run time environments with lots of abstracted functions.

So I don't think this measure is purely about language. Although some language features, like OOP, will bundle many instructions, I think it's more about building on shared libraries and packages. Higher level languages facilitate this because the code is abstracted from the underlying cpu instructions.

Improve this answer
2
  • Right. Libraries (quality and number) will have an impact as well! Commented Feb 21, 2024 at 14:38
  • Of course, if you turn that chart upside down you get an efficiency chart. It's not at all clear that more instructions == better. Commented Feb 21, 2024 at 17:13
3

Having fewer lines of code per feature is typically better as it increases the developer productivity.

I want to dig into this statement, because you are asserting this as a supposedly evident truth.

You are asserting that generating text characters (i.e. what I am doing right now in writing this answer) is the lion's share of a developer's activities to the degree that any difference in amount of text characters generated has an appreciable impact on how quickly they deliver their tasks.

You're striking at the very heart of the "LOC as a productivity metric" movement, and I can unequivocally state, with all over a decade's worth of experience as a developer, that anyone who genuinely backs this as a meaningful metric for developer productivity has not the slightest idea what a developer actually does during their daily work.

This is the equivalent of judging the performance of a car mechanic by how many screws he fastens, the quality of a novel by its word count, or the quality of the restaurant by how quickly it can serve you food. Let's be very clear here, fast food and buffets are not haute cuisine.

Let's first pick some low hanging fruit with regards to "lines of code". There are many language which do no rely on whitespacing (other than a single space character) in order to be comprehensible. In C#, it is perfectly possible to merge all your code files, and remove all newline characters from them, yielding a single line of text. Do you think that we've now somehow delivered the same codebase appreciably faster by removing the multiline nature of the codebase?

But let's not nitpick, and assume you either mean character count (regardless of whitespace) or command/instruction (i.e. what in C-style languages is delineated with a ;).

This brings us neatly into the field of code golf. So I'll just put the question to you: why do you think that the code snippets you see on CodeGolf.SE are not similar to the snippets you see on SoftwareEngineering.SE? After all, if it were the superior way of maximizing developer efficiency, we would all be advocating for code to be golfed, no?

Developers are not typists. There is a whole lot of work going on there which does not revolve around generating text characters, that non-developers are simply not privy to, because code (i.e. the text characters) is the end result of the process, not the only part of the process. It takes more than just typing these characters in order to write good, clean, observable, readable, reliable, performant and maintainable software. Each of the adjectives I just used refers to a specific subfield of software engineering that can take years to master.

Essentially, your are the manager in this parable:

There is a large manufacturing facility with hundreds of conveyor belts running non-stop—working as a system to produce whatsits. Suddenly, a malfunction happens. All the machines stop turning, the conveyor belts stop moving, and everyone stops working.

Bad news for the operation manager because they are losing tens of thousands of dollars every minute that the facility stops running. Worse, none of the technicians could track down the problem. They have looked up all the machines and gone through the manuals and SOPs, but nothing they do fixes the problem.
The manager has no choice but to call a retired technician who has worked in the facility for over 30 years. He tells the technician, "We'll pay anything, just come in and fix them."

After less than an hour, the technician arrives. He walks around for a few minutes, approaches one particular machine, and put an X on it. He then opens up the control panel of the machine. There is a bunch of tires going in all directions in the control panel.

The technician takes a dime from his pocket, turns a screw 1/4 of a turn, and asks the manager to restart all the machines. To the manager's surprise, everything starts working smoothly again. With his problem finally solved, the manager thanks the technician and asks for a bill for the work.

The bill arrives the next day—for $10,000! The operation manager is shocked and calls the technician. "There's no way it costs $10,000! You were here for less than 10 minutes and only turned a single screw. Anyone could do that." He tells the technician, "I need an itemized bill for it."
The technician doesn't say a word and resubmits a new bill. The manager takes a look at it and pays the technician without questions. Here is what the bill says:

  • $1 for turning the screw
  • $9,999 for knowing which screw to turn

Don't judge a mechanic by how difficult it is to turn a screw.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.