Lines Of Code – Dispelling The Myths

You see stuff related to Lines Of Code (LOC) everywhere on programming blogs. People discussing it as a metric of project size, or of programmer productivity, often drawing conclusions in absolutist tones such as “fewer lines of code means less bugs”. I’m writing today to dispute the idea that anything related to LOC is absolute. And I’m going to do it one myth at a time.

LOC As A Metric of Accomplishment or Project Size

This one is old, and most experienced programmers now officially reject it outright. But still, I feel it worth repeating: The number of LOC you write in a single day is worthless as a metric of what you accomplished that day. After all- If someone wrote a 1000 line class in a single day, and you wrote the same class in 500 lines (and maybe tossed in a little extra functionality while you were at it), who was more productive?

As a metric of project size, it makes a little more sense, but just barely- The Wikipedia article on LOC mentions that “Many useful comparisons involve only the order of magnitude of lines of code in a project.” That at least makes a little sense. One can reasonably assume that the same set of programmers, using the same language, will be able to accomplish more with 10000 lines of code than with 1000.

Ambiguity: Too Many Ways To Count

The next issue is this: How do you COUNT lines of code? That same Wikipedia article linked above has an interesting example:

for (i=0; i < 100; ++i) printf("hello"); /* How many lines of code is this? */

How many lines is that? One for the line? Two for logical seperation of forloop and print statement? What if you wrap the line in curly braces, one on each line, and move the comment to it’s own line, so it looks more like

for (i=0; i < 100; ++i)
/* How many lines of code is this? */

Did you see that? I just took one line of code, and turned it into 5! Things get so much more confusing than stylistic issues like this, though. What about libraries? What about frameworks? Jeff Atwood wrote a post a couple of months ago wherein he mentioned that the original version of Basecamp had been written in only 600 lines of code. Given that Basecamp was written using Ruby on Rails, which handles all sorts of crazy things for you, I think the more honest metric would have to be the 600 lines of basecamp, plus however large the RoR framework is, plus the code RoR generated for them when they started the project. Money says it’s more than 600 lines.

I’ll give you another example. Currently, the amount of code I’ve written for Migratr is 5000 lines and change. However, Migratr uses FlickrNet, a popular .NET library for interacting with the Flickr API. FlickrNet, if you download the source, is more than 12,371 lines of code (according to the unix util “wc”). I’ve also incorporated a few other libraries, all of which are linked in Migratr’s “about” page. Why? Because I didn’t want to write those 12,000 lines. Someone already had, and they did a fantastic job of it, and I didn’t see any point in re-inventing the wheel. So the total code involved in Migratr is, at this point, more than 17,000 lines. I’ve written 5,000 of them, and I’m the sole developer of Migratr. But I wouldn’t dream of saying “I built this application that interacts with a whole slew of online photo services and migrates all your photos and does all this neat stuff, and it was only 5,000 lines!” No. MY contribution was 5000 lines, but Migratr depends on a lot more than that.

The point being, where do you draw the line? Is Migratr a 5000+ LOC project? or 17,000+? Do you only count LOC if you have access to the source of the library you’re using? Do you only count the code written for your specific project? Could I export Migratr’s backend as a library and let someone write

public void migrate(String filepath)
ImportFromSource(Services.Flickr, filepath);
exportToDestination(Services.SmugMug, filepath);

Did you see that? My whole project was just replaced! Some twerp in a garage somewhere just re-wrote Migratr in 5 lines of code! It doesn’t matter that it depended on my 5,000 line library, which depends on (among others) 12,000 lines of the Flickrnet library. You only saw 5 lines. It was only 5 lines.
But clearly, since 5,000 is more than 5, I can at least say that I was more productive.

The relationship between line count and bug count only goes so far

The idea that “Less lines of code mean less bugs” is some sort of universal absolute is the biggest of all the LOC myths. In a desperate effort to nullify your “oh snap, time for a flamewar” reflex, I’m going to add a couple of disclaimers before I get into this. Any reference I make to a programming language is not an attack on that programming language, just an attack on the abuse of that language. Also, I realize that reducing the amount of code required for a specific task can help reduce the bug count, but only so far. I’m saying there’s a limit to this. Here’s the line I want to draw for you.

Reducing the code involved in a task will only help reduce the bug count IF THE PROCESS MAKES THE CODE MORE READABLE. Past that, you’re probably creating lines of code that do more than one thing per line, and thus increasing the number of bugs possible per line of code.

Perl programmers are especially frightening in this regard. I really love PERL and use it instead of shell scripting languages such as BASH whenever possible, but there’s something in the PERL culture that demands it’s programmers to try and do something in the fewest number of characters possible. There’s even a name for this as a sport- It’s referred to as “Perl Golf”.

Really quick, can you tell me what this is?

-pl s!.!y$IVCXL426(-:$XLMCDIVX$dfor$$_.=5x$&*8%29628;$$$_=$_!egfor-4e3..y/iul-}/-$+ /%s''$';*_=eval

I’ll give you a hint- It’s not a cat walking across my keyboard. If that was your first guess, though, we’re at least on the same page. This was the winning entry in a game of Perl Golf: The problem was to write a Roman Numeral Calculator in the fewest characters possible. Submissions can be found here. Now, this is an amazing piece of code. The person who wrote it is clearly very skilled. The fact that Perl makes code like that possible is pretty impressive. The problem here is that people write code like this outside of PERL golf, and think to themselves, “it’s only one line, so it must have fewer bugs than a 50 line solution”. Really? Because if I had to debug one, I’d have definitely gone with the 50 line solution. And don’t tell me that that one line of code worked on the first, second, or 5th try. The 50+ line solutions might have, but not that catwalk.
Writing unmaintanable code does not reduce the bug count for a project. A friend of mine coined a term for code like that- “Write-Only Code”- a takeoff on the permissions you can set with chmod. Think about it: Readable, writeable, and executable. Shouldn’t code be all three?

Another quick example:


The first time I saw this snippet, I thought someone was, via emoticons, trying to re-enact the facial expression one wore when seeing “Goatse” for the first time. It’s not actually a story told by emoticon. It’s a piece of scala code that sums the elements in a list. And I just don’t see it as having been easier to write than a forloop. It’s definitely not as maintainable. This piece of code, actually, prompted a conversation with a friend about holding a “code or emoticon” contest, but we really couldn’t come up with any serious contenders to this one. Maybe some Perl Golfers could throw their hat in the ring?

I want to state too, that for this section, I’m well aware that I didn’t provide buggy one-liners. I provided working one-liners. This is because I was trying to emphasize, the point isn’t if it works or not- The point is if you can tell by looking at it what it should do. If you can’t, it’s unmaintainable. If it’s unmaintanable, then even if it works the first time, it’ll produce a slew of bugs as soon as anyone tries to modify it.

So, in essence- Stop paying attention to Lines of Code. They’re impossible to count in any useful way. They’re a crappy metric of project size or personal accomplishment. And they don’t control how many bugs your code has. You do.


If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.



Доброго времени суток
Скорая юридическая помощь
Очевидно, каждый независимый житель нуждается в компетентных юридических услугах. Без сомнения, без грамотных разъяснений специалиста трудно прожить в нашем мире. Все же больше всего квалифицированные услуги нужны грамотным руководителям больших и небольших организации. В настоящее время подобные дела возможно решать удаленно. И вам не нужно обращаться к помощи таких специалистов, которые находятся в компаниях. Мы предлагаем вам воспользоваться услугами экспертов, которые организуют ип под ключ москва и предоставят вдобавок некоторое число услуг, средь которых есть ликвидация ооо. Если вы примите решение обратиться к таким юристам, то помните о том, что они в любой момент смогут предоставить вам качественный результат. И yдивляться этому не нужно! Все-таки компания отличается продолжительным опытом работы, за который удалось приобрести богатый опыт. Необходимо отметить то, что в данной организации действуют низкие цены. Следовательно, в случае если ваша фирма с зарплатным директором обратиться к таким экспертам, то она не сумеет растратить свои денежные средства. Кроме этого, вы можете при желании все время получать такие услуги и оплачивать за них небольшие деньги. В случае если вы зайдете на веб-ресурс этой компании, то вы обнаружите там весомый список разного рода услуг. В этом списке вы обязательно отыщите то, что вам надо. Нужно сообщить еще о том, что эта организация имеет возможность предложить вам высококачественный результат в очень маленькие сроки. Поэтому вам следует обратиться в эту компанию затем чтобы сберечь не только лишь личные финансы, но и личное время.
В компании «Юридическая помощь «Айсберг» — работают настоящие профессионалы своего дела. Причем Вашей проблемой займутся в команде лучшие юристы, аналитики и бухгалтеры, что даст наилучший результат.
Виды услуг
В ООО «Юридическая помощь «Айсберг» готовы решить любую Вашу проблему начиная от восстановления любых документов и заканчивая сложными вопросами наследования
кто сталкивался с этим и как оно

минимизация налогообложения

Приглашаю Вас на Живой Lineage 2 сервер
Сервак подойдет тем кто уважает неспешную стратегию с замыслом на настоящее доминирование.
Наверняка не придется по вкусу предпочитающим набежать и всех победить.
Проходящим мимо любителям побегать по сервакам однодневкам, ловить мало, т.к. старики их быстро накажут :)

What’s ᥙp, this weekend is pleasant for me, fߋr the reason that this point in time i am
reading this fantastic ᥱducational piece of writing here at my rеsidence.
Shopping for a new or used vehicle could be a tough procedure if you do not know what you are actually doing. By educating yourself about vehicle buying prior to go to the dealership, you could make stuff easier for your self. The following tips might help your following store shopping trip be a little more enjoyable.

Usually deliver a mechanic along when shopping for a fresh car. Vehicle sellers are popular for offering lemons and you do not wish to be their up coming victim. Whenever you can not get yourself a auto mechanic to check out automobiles together with you, at the very least ensure that you have him take a look at closing decision before you purchase it.

Know your limits. Before starting buying for your forthcoming vehicle or vehicle, make a decision how much you can manage to shell out, and stay with it. Don’t overlook to include desire for your estimations. You will definitely pay out about twenty percent as a payment in advance as well, so be prepared.

Well before attending a car dealership, know which kind of motor vehicle you desire. Study all you choices ahead of buying to help you evaluate which works well with your financial budget and loved ones needs. Seek information to determine how much you need to be paying for any possible automobile.

Before signing any agreement take time to study every line, like the fine print. When there is anything at all outlined you do not fully grasp, usually do not sign before you purchase an response that you simply recognize. Unsavory salesmen can use a legal contract to put many costs that have been not mentioned.

In the event you keep your previous guidance at heart the next time that you simply go looking for a automobile, you will end up more likely to obtain a good offer. Getting a auto lacks as a head ache. Use the information using this post and you will obtain the auto you desire at the excellent cost.

csgo рулетки с маленькими ставками – магазин cs go, ксго рулетка.

прогон хрумером логин скайпа pokras7777

Leave a comment