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?
God I love C.
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
If a solution is stupid and it works, then it's not stupid.
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.
Depends. Is it wrapped with #if __i386__ || __x86_64__ and followed by a #else clause that contains code without the insane optimization? If so, it is elegant. If not, it is ugly.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I mean, a lot of code is only meant for one platform type. Not writing code compatible with obsolete processors is no great sin.
Is a shortcut reliant on the finer details of a cpu - say for example the finer points of 2s complement arithmetic for type int - elegant (because it's cool) or an ugly hack (because it will probably break on some future architecture and is hard to read for the newbie)?
C originally supported many architectures when it came to number representation - 1 vs 2s compliment, 9 vs 8 bit-bytes and so one. But the current architecture is a self-fulfilling prophesy: software expects it as it's been the nom for so long, and hardware is built that way because software expects it. It's not going anywhere until we get some architecture that breaks everything anyway, even at the highest levels of abstraction, like a quantum computer. Standardization benefits everyone.
And if you're not comfortable with bit twiddling and bytewise struct layout, C probably isn't for you. Plenty of other languages in the world. Certainly if trivial stuff like (unsigned) -1 as a way to get max int bothers you, you'd probably feel more at home with high-level languages.
Socialism: a lie told by totalitarians and believed by fools.
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
Ah, but C also has the most beautiful hacks.
Absolutely; which reminds me of a piece of C code I saw years back, and which I haven't been able to find again - perhaps somebody here would happen to know it. If I remember, it was an algorithm to find the best approximation to a straight line in a bitmap, given the two end points. What I remember is that it featured a rather eye-watering construction of two overlapping switch statements (?) which was syntactically legal, but perhaps shouldn't have been. Anyway, if it rings a bell, please let me know :-)
Maybe C developers are just honest and experienced and name what it is.
I won't accuse Java, with it patterns of patterns, when there is such a easy victim like PHP.
PHP developers start their first line virtually with /* big hack */ and finish the last line with /* this is cruel */.
Is that really something to brag about?
Yes. If you don't understand why, you have no place in engineering.
it's been the nom for so long
And it's everywhere, which makes it the om nom.
systemd is Roko's Basilisk.
well, it turns out that they evaluated the ioccc repository.
world was created 5 seconds before this post as it is.
I remember something similar, called Duff's device. Not two overlapping switch statements (I don't think that's possible), but an intertwined loop and switch. I don't see any references to lines in bitmaps, but it's entirely possibe that the same kind of construction was used for that purpose too.
send(to, from, count)
register short *to, *from;
register count;
{
register n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}
I've wondered if a software VM that runs (slowly) with a unusual architecture wouldn't be helpful for finding lots of C bugs. Old C wouldn't care if it was 60 bit with 9 bit char and middle-endian.
Tom Duff was working on very high speed rendering code for Lucasfilm when he found that.
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
Depends. Is it wrapped with #if __i386__ || __x86_64__ and followed by a #else clause that contains code without the insane optimization? If so, it is elegant. If not, it is ugly.
I would say it would depend even more on whether or not the programmer profiled the code in question prior to making that optimization change. If there is no perceived or noticeable benefit to this optimization, then there is no reason to put something unreadable and platform specific into your code base. I know I worked on a project once where the dev manager wanted to rewrite an entire library in assembly because there was a perceived performance problem in the library. While some more senior devs started the work on that, I profiled the library and saw that it was just one function call that was accounting for most of the performance problems. I also realized that this function call was being made 1200 times per second when we really only needed to make this call once and then we could cache that result. There is no point in putting in any sort of clever hack or optimization until you've identified a need for it. Most modern C/C++ compilers are pretty good at optimizing your code for you.
Wrapping it in ifdefs doesn't make it elegant. It just makes it not a hack. Instead, it makes it ugly, and correct.
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.
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.
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!).
That should be your reaction by default because change always incur costs and risks. So better have a valid reason to incur in new costs and risks. The operation of something old has to be costly, or difficult, or subpar, or the change to something new has a real chance of decreasing costs, or the change is part of a larger, business-related strategy. Only then you have a valid reason to change.
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!"
The cost of electricity and maintenance costs may appear high, but if they are constant and well known, then they imply minimum risk. You can account them for (and you should if you are running a business, ... otherwise, don't run a business.)
If maintenance costs are limited to hardware support, you can ignore them. If it is software costs in terms of difficult deployments or software upgrades, then yes, that is the threshold over which a change needs to be initiated.
But if you don't have that, then, don't fix what is broken. Let the cost be constant and the risk known (and ergo manageable.)
It's why many COBOL programmers still have a job.
No. It is because most COBOL systems are running within expected parameters. After running for years, if not decades, they are well known, their features and their glitches. They are battle tested.
And given the large size of these systems, it would be ridiculous to re-write them into something else. Why? Because that implies unknown risks and costs. Risk is something that grows exponential to the size of the re-write. This is not hand waving, this is a fact.
There is more to software engineering than writing code. It also involves delivering solutions and values and managing risk. Software engineering must be seen as integral part of a business process. Otherwise, we are not software engineers, but mere code monkeys throwing shit at the wall, packaging and selling whatever sticks.
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.
I remember that! It's why the C standard allows a void* to be bigger than an int* - char*s on Cray's needed extra bits for sub-memory-address-addressing.
Socialism: a lie told by totalitarians and believed by fools.