Slashdot Mirror
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.
Pretty sure people already assume that every line of Perl code is an ugly hack anyways, so they didn't have to write a comment on it.
Regardless this seems like a pretty crappy study. There's many other phrases like kludge or XXX to have considered.
Seriously guys. File this one under "NO SHIT" - Of course C is going to have the most ugly hacks. Why? Because it is by design able to access a hell of a lot more than other languages. How many languages have direct hardware access? Or inline ASM code? And does the word "hack" in the code really make it an "ugly" hack? Seriously? I wrote a micro-kernel for an ARM platform about a decade ago, and there was an assload of inline ASM code and direct pointer manipulation to access the underlying hardware, there is no other way to do this. Yeah, I'm sure the word "hack" appeared countless times in my code, because that's the general term we use. That doesn't make it "ugly" or bad by any means.
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-)
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?
Perl was last on that list?
For those people who say that Perl coders only write incomprehensible gibberish, I say:
BWA HA HA HA HA!
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.
#ifndef __INCif_etherh /* Quick and ugly hack for VxWorks */
// ugly hack because we don't have fscanf
/* ugly hack to make it compile on RH 4.2 - WA */
/* ugly hack GRR */ /* nothing */
/* XXX argh, ugly hack to make stuff compile! */ ...) sprintf(BUF, __VA_ARGS__)
int fscanf(FILE* stream, const char* format, int* value)
#else
#include
#endif
#if !defined(__GNUC__) && !defined(__common_include__)
#define __attribute__(x)
#define snprintf(BUF, SIZE,
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 /. ...
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.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
C Code EVERYWHERE has the most "ugly hacks"
Ah, but C also has the most beautiful hacks.
"Ugly Hack" very often means the programmer has done a smart thing, if not an exactly correct thing. Although sometimes an ugly hack is just an ugly hack.
"/* 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.
Nullius in verba
C code is ugly hacks. But how else are you going to write an efficient ring buffer?
Check out my sci-fi/humor trilogy at PatriotsBooks.
I think the key difference here is that when someone uses C they want efficient code to some extent. Small, or fast, or both. In other languages the culture is often "do it in the method approved by the sacred elders", and so ugly hacks may be forbidden and the slow/bulky method is preferred, according to the mantra "do not reinvent the wheel because thou are not as wise as the wheel builder". Or the presence of an ugly hack implies that the novice must clearly have been prematurely optimizing, for as the wise men say tomorrow is too soon to optimize.
For example in Python the claim is that there's almost always only one way to do something, which either means ugly hacks are not possible, or else there's a lack of imagination amongst the programmers.
The higher level a language is, the more it seems that the goal is to get stuff done fast rather than efficient or elegant.
Finally, I have actually seen cases where code is labeled an "ugly hack" when it really wasn't a hack at all but rather not as tiny or or elegant as the author wanted.
For ugly hacks, you can't beat trying to optimise string ops 8 bit bytes on a 60 bit (Cray) processor - they natively used 6-bit chars, and packed four 15 bit instructions in a word, but required jumps to be aligned on a double word boundary to avoid pipeline stalls. Apart from assembler, I think C is probably the only language that could do it at all.
(I it tried in Fortran and then realised there were better things to do in life).
Sent from my ASR33 using ASCII
Is that really something to brag about?
Yes. If you don't understand why, you have no place in engineering.
C coders know when they are using ugly hacks and would take a moment to comment it or name the function with the term ugly hack. They realize it is not elegant and make a note so that future developers do not think it is a reference implementation worthy of replication and emulation. It is basically "this is probably not worth copy/paste, do a fresh implementation".
Other language coders might be using these ugly hacks with pride not knowing anything better.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Wrapping it in ifdefs doesn't make it elegant. It just makes it not a hack. Instead, it makes it ugly, and correct.
This is a complete and total lie. There may be one "good" way to do something (for values of good), but there are many ways of doing soemthing.
It's not a "complete and total lie." The Zen of Python, "Python Enhancement Proposal #20", states:
There should be one-- and preferably only one --obvious way to do it.
It's one of the guiding principles of the language's design. Type "import this" into a Python command-line, and PEP20 gets printed out.
It is pitch black. You are likely to be eaten by a grue.