On Wed, 2021-03-17 at 11:57 +0100, Stefan Hundhammer wrote:
On 2021-03-16 23:01, David Díaz wrote:
On a final note, I have learned that the simple "wc -l" command becomes a completely different thing when talking about counting LOC ;)
It's a matter of definition, of course, what exactly a "line of code" actually is.
Like all metrics, it needs to be used wisely, and at the same time we need to keep in mind that it's just a number that by itself doesn't tell anybody very much.
Agree
During my career (spanning when I began programming in the early 1980s to studying computer science 1986-1991 to starting in my first paid job in 1991 to today) I have seen many people producing tons of lines of code that can hardly be compared.
I have seen copy&paste programmers who produce enormous numbers of LOC of questionable quality that others would have condensed into a fraction of that with smart use of reusable, parameterized functions (and later objects).
I have seen people programming highly optimized hand-written Assembler for use in mobile phones on the GSM layer where a hard timer interrupt after n CPU cycles makes it an absolute requirement to be finished with your timer loop within that time, or the system will crash; so those people were sitting for days on end to save a line of (Assembler) code here and a line there. Their achievement was clearly not boasting lots of LOC, but minimizing it.
I have seen people writing tricky, short code that was not self-explanatory at all where some lines more would have clarified a lot.
I myself tend to add a lot of comments explaining things in the code and, more importantly, in function or class headers. And I use a lot of empty lines to make clear separations between functionally related and unrelated things.
And I keep seeing that legalese garbage that some people claim corporate lawyers require us to add to each and every source file (as comment lines, but that's comments that are not useful to anybody in the world, it's just useless gibberish), at the same time not a single word at the file header WTF that code is all about.
How does all that stack up with the various definitions of LOC? Does the definition really make sense?
So, any measure of LOC is completely arbitrary and really cannot be compared. It's just a pointless number. It may be an impressive number, but it's still just a number. Don't get over-excited by such numbers.
I don't ;)
Add to this the fact that YaST is a project with a 20+ years history; we started back in late 1999. During that time, lots of code have been added, edited, removed. You always only see the last state; a snapshot of what happened over time. Just adding up the LOC does not tell the whole story.
You're right.
In fact, it's downright deceiving.
As all of you surely know, sometimes you need to do many hours (or even days) of research to find out what a particular block of code is all about; what it was originally meant for, what of that is still relevant today, what is obsolete, and what it means to change it in any way. And then you have a patch of 5 lines added and 5 lines removed to prove for what you did over 3 days, and the overall LOC count is the same as before.
That's true.
That doesn't sound impressive at all.
In that aspect, more often than not we are in the role of archaeologists and/or restaurators; you can't simply compare what we do with some newbie fresh from university writing some Ruby-on-Rails application.
It would be comparing a house painter whitewashing a wall with a restaurator restoring a medieval fresco on a church ceiling to its old glory. Sure, we could simply whitewash it, but that would probably not make anybody happy. ;-)
Just my 2 Cents^W^W Ok, that was more like 10.- EUR ;-)
Thanks!
Kind regards
-- -- David Díaz YaST Team at SUSE LINUX GmbH IRC: dgdavid