I find lines of code to be a useful measure for complexity, whether inherent or incidental. High lines of code per file / function is a good start to determine problematic sections.
It is definitely not a measure of work. As developers, we don't produce code, we use code to solve a problem.
I can easily use several tens of lines of code for list comprehension/transformation and aggregation, but for the same task can also use one mathematical formula.
However, it can also mean that the programmer did format the code to better reflect the actual task accomplished.
It can also show that a module/file/class contains a lot of code that can/should be split up.
There is not "one reason" for filesize, no matter whether it be small, medium, or large.
A high amount of lines of code says literally nothing at all.
Do not at all, ever rely on that.
For instance, said script contained about 100 lines of code (getting/reading parameters) that wrapped 5 lines of actual code (send to CouchDB).
Of course, LOC should not be taken as a hard rule, but they can be an indicator of code that needs to be refactored, especially if it is touched frequently.
In the case of your script, it is very likely that the reader does not care about the i/o boilerplate, so that could as well be in another file or at the bottom of the same file. Then you would have one short script that is read often and a long script that is read rarely.
BTW, despite thinking that it is useful as an indicator for complexity, I absolutely agree with you that LOC per time is not a good way to measure effectivity or productivity.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I find lines of code to be a useful measure for complexity, whether inherent or incidental. High lines of code per file / function is a good start to determine problematic sections.
It is definitely not a measure of work. As developers, we don't produce code, we use code to solve a problem.
I don't think it's like that.
I can easily use several tens of lines of code for list comprehension/transformation and aggregation, but for the same task can also use one mathematical formula.
However, it can also mean that the programmer did format the code to better reflect the actual task accomplished.
It can also show that a module/file/class contains a lot of code that can/should be split up.
There is not "one reason" for filesize, no matter whether it be small, medium, or large.
A high amount of lines of code says literally nothing at all.
Do not at all, ever rely on that.
For instance, said script contained about 100 lines of code (getting/reading parameters) that wrapped 5 lines of actual code (send to CouchDB).
Of course, LOC should not be taken as a hard rule, but they can be an indicator of code that needs to be refactored, especially if it is touched frequently.
In the case of your script, it is very likely that the reader does not care about the i/o boilerplate, so that could as well be in another file or at the bottom of the same file. Then you would have one short script that is read often and a long script that is read rarely.
BTW, despite thinking that it is useful as an indicator for complexity, I absolutely agree with you that LOC per time is not a good way to measure effectivity or productivity.