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
