C Code On GitHub Has the Most "Ugly Hacks"

itwbennett writes: An analysis of GitHub data shows that C developers are creating the most ugly hacks — or are at least the most willing to admit to it. To answer the question of which programming language produces the most ugly hacks, ITworld's Phil Johnson first used the search feature on GitHub, looking for code files that contained the string 'ugly hack'. In that case, C comes up first by a wide margin, with over 181,000 code files containing that string. The rest of the top ten languages were PHP (79k files), JavaScript (38k), C++ (22k), Python (19k), Text (11k), Makefile (11k), HTML, (10k), Java (7k), and Perl (4k). Even when controlling for the number of repositories, C wins the ugly-hack-athon by a landslide, Johnson found.

Comments

Maybe C developers are more honest

[angryargus]

Regardless this seems like a pretty crappy study. There's many other phrases like kludge or XXX to have considered.

Re:Maybe C developers are more honest

[Anonymous Coward]

C developers are good enough to know when what they're doing is an ugly hack.

If PHP developers were at the same standard, every line would end with // Ugly Hack.

Re:Maybe C developers are more honest

[dgatwood]

C developers are good enough to know when what they're doing is an ugly hack.

If PHP developers were at the same standard, every line would end with // Ugly Hack.

I think the reason PHP is #2 on the list is that the people who are still writing PHP are mostly pretty good. The ones who were awful have all moved on to Python or Ruby or whatever the scripting language of the week is these days.

In fact, I'd be willing to bet that a sizable percentage of the folks who are still actively using PHP are C programmers. I use it for all my web programming because it is exceptionally easy for me as a long-time C programmer. I basically write C with dollar signs and a few other minor tweaks, and it works. Even better, if there's some piece of code that has to be blisteringly fast, I can port it from PHP to C faster than you can say sed 's/\$//sg'. Okay, it really isn't quite that trivial, but it is pretty close.

And yes, I do occasionally take advantage of being able to mix PHP and HTML, but not very often. I mostly just use it as a compile-free web programming language with better string handling and basic support for classes.

There might be a bit more to it.

[hamster_nz]

C coder know a ugly hack when they see one, and when they write one.

I would conjecture that nearly every line of Perl scripts is an ugly hack, so nobody bothers to add a comment... 8-)

The ultimate ugly hack?

[hamster_nz]

Fast inverse square root (sometimes referred to as Fast InvSqrt() or by the hexadecimal constant 0x5f3759df) is a method of calculating x1/2, the reciprocal (or multiplicative inverse) of a square root for a 32-bit floating point number in IEEE 754 floating point format.

http://en.wikipedia.org/wiki/F...

Anybody got any better Ugly Hacks to share?

Re:The ultimate ugly hack?

[Anonymous Coward]

Duff's device

C's default fall-through in case statements has long been one of its most controversial features; Duff observed that "This code forms some sort of argument in that debate, but I'm not sure whether it's for or against."

Ugly but beautiful

[Anonymous Coward]

God I love C.

Nonsense...

[SlovakWakko]

The whole C language is one beautiful hack, scary at first but once you get to know it in some really messed up sw project you can't help but love it. The balance between freedom and structure is excellent.

Heavy duplication

[x0ra]

Every single page has many occurence of the same "ugly" hack. If the folks who did the study had an ounce of legitimacy, they would have filtered for all those duplicates. If they had actually been competent, they would have done an in-depth study of all those "ugly hack". Of course, at this point, the article would have been worthless, but hey, they got their first page on /. ...

Only meaningful if weighted

[blind biker]

These numbers should be weighted to the amounts of code in the various programming languages on GitHub. There may be lots of C "codefiles" with the "ugly hack" string in them, but there probably is a lot of C code overall on GitHub, too.

Re:File this under "NO SHIT"

[AmiMoJo]

Maybe the reason C has more is that the specific string "ugly hack" is more commonly used by C programmers. Languages like Javascript are really ugly and full of nasty hacks, but that's normal for them so no-one comments on it.

Re:Such is C

[ShanghaiBill]

C Code EVERYWHERE has the most "ugly hacks"

Ah, but C also has the most beautiful hacks.

Re:Low hanging hack...

[chiasmus1]

After looking at those examples, it seems to me that C programmers can claim something is an "ugly hack" because it was not what they wanted or because someone else's code was messed up. The C code hacks where there because they could not see an elegant solution. Programmers for other languages probably do not even know that the code they are writing is ugly.

it's a C idiom

[bugs2squash]

"/* ugly hack to... */" is a modest expression of pride describing concise, functional, readable and elegant C code in the same way as the term "//elegant approach to..." in C++ describes some borderline-insane misapplication of the STL with the incomprehensibility of perl and the verbosity of java.

Re:File this under "NO SHIT"

[someone1234]

In this study, an ugly hack was determined by the string "ugly hack" appearing in code comments. It was a totally scientific study.

Re:Such is C

[dgatwood]

C Code EVERYWHERE has the most "ugly hacks"

C code is ugly hacks. But how else are you going to write an efficient ring buffer?

Re: Such is C

[luis_a_espinal]

Is that really something to brag about?

Yes. If you don't understand why, you have no place in engineering.

Re:Such is C

[michelcolman]

Ideally, you should include a generic version without any hackish optimizations, but it isn't strictly required if you don't think you'll ever change CPUs in the future.

And then your company upgrades its CPUs while you're long gone, and now they need to figure out who the hell wrote that crappy piece of code that keeps crashing on the new CPU, and some other programmer has to rewrite everything from scratch because they can't figure out how your code works and why it's not doing what it's supposed to be doing.

By the way, that other programmer may just be an older version of you who has completely forgotten what the younger version did there... (not that I have any experience with that, cough)

Re:Such is C

[beelsebob]

Wrapping it in ifdefs doesn't make it elegant. It just makes it not a hack. Instead, it makes it ugly, and correct.

Re: Such is C

[wed128]

The only reason you would have that code still running on those chips is because it's not forward compatible with something more modern.

Or the bean counters don't want to pay the up-front cost of moving to something more modern. Many financial departments take a 'if it ain't broke' stance on computing hardware (and software!). many of them don't factor in electricity and maintenance costs, all they see is "$N Dollars for new server hardware? Why? That's rediculous!"

It's why many COBOL programmers still have a job.

Re: Such is C

[luis_a_espinal]

The only reason you would have that code still running on those chips is because it's not forward compatible with something more modern.

Or because those platforms are running fine for the job they are required to do, and thus replacing them do yield any additional value? Proper engineering and business decisions call for changing things when you have to, when you have a reason, a valid reason.

If it ain't broke, don't fix it is not just an empty slogan.

Otherwise someone would have transitioned to some much cheaper, more recent, commodity hardware, and saved the business a lot of cash.

Why cheaper? What if the hardware is already owned? What if the systems therein are running just fine as expected? If it ain't broke, don't fix it

That's definitely not good engineering, or something to brag about.

If it ain't broke, don't fix it. If you don't get it, you are not cut for this business.

Do we go about rewriting all those lines of working-fine COBOL code into whatever is in vogue nowadays? Do you change your working-condition car every time a new model comes?

The only time you change something is if you have a reasonable expectations of gains, or if the cost of keeping something that old goes above a certain threshold. Otherwise, you let it be.

You know you are doing it right when your creation becomes legacy, and it runs unchanged for years, many years, providing value and ease of integration. That is, when the thing you created delivers value AND does not give reasons to decommission, then you know you did your job right, and you can brag about it.