Today's article is an easy one, where we learn to count things...

[KGIII]

Have you ever wanted to count the words, letters, or lines in a file? Well, you can! There's a tool called 'wc' and we use it to count things because we love counting things!

Or not... Really, how often do you need to count stuff from the terminal? But, if you do want to count things, we cover the three most-likely ways you'll use the 'wc' command in your day-to-day computing. There's more to it, so be sure to check the man page.

How To: Count Letters, Words, and Lines • Linux Tips

Today's article isn't going to be all that interesting unless you happen to want to know how to count letters, words, and lines in a file.

linux-tips.us

 

[camtaf]

Writers & journalists often need to know how many words they have written, sometimes their payment may depend on it, or used to be.

 

[vs2-free-users]

Hi,

i use wc -l often to count lines in my bash scripts.

 

[sphen]

Writers & journalists often need to know how many words they have written, sometimes their payment may depend on it, or used to be.

Thank goodness TuxBot is not paid by the word here. :-(

 

[KGIII]

i use wc -l often to count lines in my bash scripts.

I'd touched on writers, but why would you count the lines in your bash scripts?

That's something I'd do if I'm curious, I suppose... It'd not be often or anything like that. If I'd written a particularly long script and wanted bragging rights, I might count it.

 

[sphen]

I'd touched on writers, but why would you count the lines in your bash scripts?

That's something I'd do if I'm curious, I suppose... It'd not be often or anything like that. If I'd written a particularly long script and wanted bragging rights, I might count it.

Software development project management typically count lines of code to track progress. Counting lines is easy. Interpreting the numbers and gaining insights is not. In fairness, few count "newlines" (returns). The counting tools recognize blank lines, comments, type of code, etc.

If the project has a lot of bash scripts (say, a Linux distro, perhaps?), then it might be useful to track lines of shell scripts just like other code.

As @KGIII implies, I doubt that many people bother to count lines on personal projects, whether bash scripts or anything else.

 

[KGIII]

Software development project management typically count lines of code to track progress.

That seems like a REALLY bad metric thought up by PHBs.

I understand that tracking productivity is important and not easily done in this field, but tracking LOC seems like a horrible idea. Though, it might give some incentive to add code comments. So, there's that...

There was a milestone when the kernel reached a million LOC, but I don't think that was much of a productivity milestone - more just a 'oh, wow' milestone. I believe the kernel is now many millions of LOC. There was an article about that not too long ago.

 

[sphen]

Actually, source lines of code is a very common metric, certainly for larger projects. I skimmed this Wikipedia article and it covers the basics:

Source lines of code - Wikipedia

en.wikipedia.org

People may be shocked at two values:

Total Lines of Code for Any Modern Operating System
Take the time to look at the Wikipedia article. Scroll down to see lines of code estimates for old versions of Windows and Linux.
-> It says that Debian 7 (2012) had 419 million lines of code. It is a staggering number to me and that was over 10 years ago.

Estimated Debugged Lines of Code Per Developer Per Day
Project leaders use "debugged lines of code per developer per day" values as one aspect of project planning. One of my favorite books on this subject is "The Mythical Man Month" by Fred Brooks, published in 1975. It is a seminal work in the field; a post-mortem of the lessons learned from managing IBM's System 360 project.
-> In that early book, the author tells us to estimate 10 "SLOC" (source lines of code) per developer per day.

(I never saw anyone use boosted lines per day values (e.g., 20 or above) and get away with it. I view it as an "anti-pattern" - a behavior which will lead to failure. From my experience, sellers promote products that claim to yield huge increases in developer productivity. Management "drinks the koolaid" and takes the product or service hype as the basis for unrealistic estimates of cost and schedule for the future project. Sometimes it is a deliberate trick to win a contract or executive approval, with the expectation that overruns will be covered in other ways - change orders, too late to cancel, etc. Sorry to be so brutally honest about it.)

Related, and equally shocking to average people:

Bugs per 1000 Lines of Code
Look up typical numbers for "bugs per 1000 lines of code". Those are the bugs that still remain in your products. They shipped the product to you anyway, knowing that it had bugs. (Imagine that!) A few of the bugs are known, most are not, and most will never be triggered, ever. Values range a lot and need context. Do a quick search for "bugs per 1000 lines of code."

VERY IMPORTANT:
Many bugs may never be encountered in real life, which may be why they were not caught. Individual developers vary wildly in their production levels. The most productive developers may also be the ones who generate the fewest bugs.

Without context, understanding, and proper interpretation, you can easily jump to unwarranted conclusions.

Do not ascribe too much value or utility to this post. It is as more about sharing those unexpected numbers for your amusement than it is about providing you with useful information that you can apply to your Linux systems. You won't win bar bets with it.

Ignore:
(One developer who worked for me could easily generate hundreds of lines of code a day. Okay, some days, but she was very productive. She was beloved by all for her ability to create proof-of-concept but fully functional demonstrations very quickly. Customers were "wowed." The problem was that nobody could read, understand, review, modify, or maintain any of her code. Putting her in a production environment would have been two tragedies - to the team and her.)

 

[KGIII]

Actually, source lines of code is a very common metric, certainly for larger projects. I skimmed this Wikipedia article and it covers the basics:

To be more clear, my reply was a bit tongue in cheek. I know of the LOC measurement but never used it.

Instead, I did things like peer review.

I'm a horrible programmer and hired professionals as soon as I realistically could. Seriously, I am horribly at it. They say it requires a logical mind - and I'm a mathematician. I guess I dislike it because it's like learning another language - except when you make it mistake a native speaker kicks you in the groin.

But, yeah, I'm familiar with LOC - but I don't agree that it made sense for us to use that as a performance measurement. If someone isn't pulling their weight, it'll come out in peer reviews and then we can work with them to build proficiency.

 

[vs2-free-users]

I'd touched on writers, but why would you count the lines in your bash scripts?

That's something I'd do if I'm curious, I suppose... It'd not be often or anything like that. If I'd written a particularly long script and wanted bragging rights, I might count it.

Hi,

for example this little snip

root@srv27595:~# netstat -ntu | grep ':443 ' | wc -l
11

Shows the current connections to port 443 (https) on my server.

 

[KGIII]

Shows the current connections to port 443 (https) on my server.

Ah, when you said bash scripts I thought you meant things like scripts you'd written - not that you were piping the output to wc.