But it can be assumed that code length is rarely free, and thus, longer code is often harder to manage. If I were managing a team of programmers, I would very much want to keep track of the ballast it creates or removes. Explain that SLOC is an excellent measurement of the lines of code in the application, nothing else.
The number of lines in a book, or the length of a film doesn't determine how good it is. You can improve a film and shorten it, you can improve an application and reduce the lines of code.
The idea is this: a developer should commit a test case that fails, then commit the fix in next build, and the test case should pass You don't judge how good how many features,how it performs.. When you want your plane to fly higher, longer and perform better, you don't add weight to it.
You strip off parts you don't need as to not add unnecessary weight. I believe SLOC is a great metric. It tells you how large your system is. That is good for judging complexity and resources. And it helps you prepare the next developer for working on a codebase. I have been managing software projects for 30 years. I use SLOC count all the time, to help understand mature systems. I have never found it useful to even glance at SLOC count until a project is near version 1. Basically, during the development process, I worry about quality, performance, usability, and conformance to specifications.
Get those right, and the project will probably be a success. When the dust settles, look at SLOC count. You might be surprised that you got SO much out of 5, lines of code. And you might be surprised that you got SO little! But SLOC count does not affect quality, performance, usability, and conformance to specification. And always code like the person who will be working on your code next is a violent psychopath who knows where you live.
You need to carve, say 10 statues. It's not how many statues you carve that counts. It's how well you've carved it that counts. Similarly it's not how many lines you've written but how well they are functioning. In case of code LOC can backfire as a metric this way. Productivity also changes when writing a complex piece of code. It takes a second to write a print statement but a lot of time to write a complex piece of logic.
Not all fingers are equal. Yes the difficulty level comes into play but this is a good parameter that the managers can throw around while doing business. Try to think from their perspective too. They don't hate you or your work, but they need to tell customers that you're the best and for that they need something tangible.
Give them what you can :. SLOC can be changed dramatically by putting extra empty lines "for readability" or by putting or removal of comments. So relying on SLOC only can lead to confusion. Why don't they understand that the SLOC hasn't changed, but the software does more than it did yesterday because you've added new features, or fix bugs? Now explain it to them like this. Measuring how much work was done in your code by comparing the lines of code is the same as measuring how many features are in your cell phone comparing it by size.
Cell phones have decreased in size over 20 years time while adding more features because of technological improvements and techniques. Good code follows this same principal as we can express the same logic in fewer and fewer lines of code, making it faster to run, easier to maintain, and simpler to understand as we improve our understanding of the problem and introduce new techniques for development.
I would get them to focus on the business value returned through feature development, maintenance, and bug fixes. If whoever is happy with the software says they can see improvement don't sweat the SLOC. Load Comments. What's New. Most popular in Difference Between. Most visited in Software Engineering. We use cookies to ensure you have the best browsing experience on our website.
I personally think that a much better metric to express productivity is through number of PRs merged or the average time to close of PRs produced by a developer.
There are of course many other traditional metrics that you can track and follow like Cyclomatic complexity, Code churn, Code coverage, Code duplication, etc. Codacy is used by thousands of developers to analyze billions of lines of code every day! Getting started is easy — and free! Just use your GitHub, Bitbucket or Google account to sign up. Save my name, email, and website in this browser for the next time I comment. Automatically identify issues through static code review analysis.
Get notified on security issues, code coverage, code duplication, and code complexity in every commit and pull request, directly from your current workflow. Sign in. Log into your account. Forgot your password? Password recovery. Recover your password.
However, functionality is less well correlated with SLOC: skilled developers may be able to develop the same functionality with far less code, so one program with less SLOC may exhibit more functionality than another similar program. In particular, SLOC is a poor productivity measure of individuals, since a developer can develop only a few lines and yet be far more productive in terms of functionality than a developer who ends up creating more lines and generally spending more effort. Good developers may merge multiple code modules into a single module, improving the system yet appearing to have negative productivity because they remove code.
Also, especially skilled developers tend to be assigned the most difficult tasks, and thus may sometimes appear less "productive" than other developers on a task by this measure. Furthermore, inexperienced developers often resort to code duplication, which is highly discouraged as it is more bug-prone and costly to maintain, but it results in higher SLOC. SLOC is particularly ineffective at comparing programs written in different languages unless adjustment factors are applied to normalize languages.
Various computer languages balance brevity and clarity in different ways; as an extreme example, most assembly languages would require hundreds of lines of code to perform the same task as a few characters in APL. The following example shows a comparison of a "hello world" program written in C, and the same program written in COBOL - a language known for being particularly verbose.
Another increasingly common problem in comparing SLOC metrics is the difference between auto-generated and hand-written code. Modern software tools often have the capability to auto-generate enormous amounts of code with a few clicks of a mouse. For instance, GUI builders automatically generate all the source code for a GUI object simply by dragging an icon onto a workspace.
0コメント