C Code On GitHub Has the Most "Ugly Hacks" 264
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.
Perl (Score:5, Funny)
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.
Re:Perl (Score:5, Funny)
To recognize that a line of code is an ugly hack, someone would have to first understand it, and as we all know, only Perl can parse Perl.
Maybe C developers are more honest (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
Just WordPress developers. No, I take that back... WP devs are so shit that they wouldn't recognize any hack.
Re:Maybe C developers are more honest (Score:5, Insightful)
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.
Re: (Score:2)
* And in some cases, even tested too!
Re: (Score:2)
Well, of course - it only counts how many occurences of a certain string you can find. An alternative interpretation could be that since people would have to know what beautiful code looks like in order to decide what ugly code looks like, there must be far more C programmers who know how to write good code. Which makes sense, I think; C is a language that allows the coder to make horrible mistakes, so in order to survive, you have to develop a coding style with strong discipline, which is what makes beauti
Re: (Score:3)
Re:Maybe C developers are more honest (Score:5, Informative)
https://github.com/search?utf8... [github.com]
Javascript wins.
PHP developers prefer murdering kittens: https://github.com/search?utf8... [github.com]
Some other fun facts:
C developers are most ashamed of their code: https://github.com/search?utf8... [github.com]
PHP coder don't fix bugs: https://github.com/search?utf8... [github.com]
C developers' code actually get worse as it ages: https://github.com/search?utf8... [github.com]
Java developers seem to have the most trouble getting their code to work: https://github.com/search?utf8... [github.com]
Not surprising: https://github.com/search?utf8... [github.com]
Disclaimer; not corrected for any type of bias or error, of which there are many.
Re: (Score:3)
Haha, neat .... but ....
try {
} finally {
working = true;
}
So no, I don't think it shows anything about Java. If you want to get a similar string for Java I'd suggest variants on "TODO: Refactor this". Java has very powerful refactoring IDEs and the corporate world has more of an emphasis on constantly refactoring stuff
Re: (Score:3)
Dear God Why?
https://github.com/search?utf8... [github.com]
Ugly as sin (Javascript wins, C a close second)
https://github.com/search?utf8... [github.com]
"BUG" (Holy God, 52 million entries in C, Javascript has 5.4m in second)
https://github.com/search?utf8... [github.com]
TODO (20.9 million C entries, 7 million on PHP in second)
https://github.com/search?utf8... [github.com]
FIX (24 million C entries, 6.3 Javascript in 2nd)
https://github.com/search?utf8... [github.com]
"Why does this work?" (C, 2.9 million, C++ 307,942 in 5th place)
Re: (Score:2)
Or maybe they're simply aware of what is ugly and what is not.
I develop PHP for a living and a while back I encountered a styleguide which said you should give function arguments. Code like 'function f($a, $a, $a) actually works in PHP. This in itself this as insane enough, but... some developers are retarded enough to require a styleguide to tell them not to do that. You think any of those developers will be able to tell the difference between an ugly hack and good, clean code?
My guess is that most of this
File this under "NO SHIT" (Score:5, Interesting)
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.
Re: (Score:3)
Re:File this under "NO SHIT" (Score:5, Informative)
Honestly, for some of us "hack" means anywhere from "an inelegant but necessary workaround", to "a really awesome and unexpected use of something", to "defeating system security", or a clueless person bashing away at something they don't understand, or "something I just whipped up".
GP is absolutely correct ... for many of us, "hack" is a very generic term.
Re:File this under "NO SHIT" (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
For languages like JavaScript, it's such an easy/accessible/portable language I actually wonder what the breakdown is. Just like every other language there are people who are really proficient in JS and aware of good practices and design, but there are also people who are so used to learning from ugly hacks of others they may feel it's acceptable, or they just have so little background with good code they have no idea that half their program constitutes an ugly hack. C certainly has a higher barrier to entr
Re: (Score:3)
I would also add that the most common reason why people write "ugly hacks" is to make their programs fast. If you care enough about speed to put these ugly hacks in your program, you're certainly not going to write it in Java or Python.
Re: (Score:3)
Re: (Score:3)
[Y]ou must be one of the people who think 2 + 2 = 5 for large values of 2.
Well obviously 2 + 2 never equals 5, duh! ...
2 + 2 approaches 5 as the value of 2 grows
Re: (Score:2)
Well, I'm mostly a Ruby programmer. :D
So yes, Java and Python+Numpy are fast for me
Re:File this under "NO SHIT" (Score:5, Insightful)
In this study, an ugly hack was determined by the string "ugly hack" appearing in code comments. It was a totally scientific study.
Re: (Score:2)
Re: (Score:2)
I agree, that's not a hack. I work on bootloaders and need to directly access low-level hardware registers and whatnot on 64-bit MIPS processors. I only need about a page of assembly code to do things like set up part of the L1 cache as stack memory and initialize a few registers before switching to C code. For some of the registers that require assembly to access we have macros to hide it. I certainly don't consider it a hack. Even inline assembly isn't necessarily a hack since some things require it, suc
There might be a bit more to it. (Score:5, Insightful)
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-)
Re: (Score:2)
I'd love to see standardisation across languages for FIXME and TODO too, then it would be easier to distinguish the two cases, where they ARE distinct.
Actually there are a lot of very big Perl codebases, well written and commented [and some atrocious ones, like every othe
The ultimate ugly hack? (Score:5, Insightful)
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... [wikipedia.org]
Anybody got any better Ugly Hacks to share?
Re:The ultimate ugly hack? (Score:5, Insightful)
Duff's device [wikipedia.org]
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."
Re: (Score:2)
Eh. I don't have a problem with the fall-through. Interleaving the switch cases and the do/while makes me shudder.
Re: (Score:2)
But that's mostly a C implementation of unrolling, something that would be perfectly normal in assembler code. But then there are the programmers who in their effort to banish all forms of Fortran style spaghetti code reject anything that can't be easily reworked with IFs and WHILEs. It probably also horrifies some programmers who think it's premature optimization (if it's not yet the end of the world then it's too soon).
Re: (Score:2)
Right now I am working on a project with a 4,000 line function, related classes scattered across multiple projects so they can't compile easily, objects from the messaging library used throughout so it can't be easily un-coupled, objects whose purpose is unclear and don't make sense even when it becomes clear. Not to mention inefficiencies that mean it is several orders of magnitude slower than it would be if written in [any language, really, as long as the design
Re: (Score:3, Funny)
Swallow your pride and just give up, Lennart.
Re: (Score:3)
float->int conversion used to be expensive on x86 processors due to default rounding modes from C, and lack of suitable built in rounding functions. Looking back, my code contained this handy function. Ugly hack or elegant performance improvement? I'd suggest that the difference comes down to comments, unit tests, and whether people die if it's got bugs ;-)
#ifdef WIN32 // This method relies on knowing the rounding mode of the float processor // // It rel
#ifdef ASSUME_ROUNDING
Re: (Score:2)
Those that think that its an "ugly hack" to do so are computer science illiterate. Like that other guy that thinks leveraging twos-complement is an ugly hack.
Pretenders dont know what ugly hacks are. You are one of them.
Re: (Score:2)
For me XOR swap was always an example of hack which is extremly ugly if not commented.
http://en.wikipedia.org/wiki/X... [wikipedia.org]
Ugly but beautiful (Score:2, Insightful)
God I love C.
Re: (Score:2)
Re: (Score:2)
You're right. Number of files? Comment language? Size? History length? Just a few parameters that seem to influence the likelihood with which "Ugly hack" appears. Nope, first a good model, then the analysis.
Re: (Score:2)
Nonsense, it distracted me from my humdrum existence for a few minutes.
Perl was last? (Score:4)
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!
Re: (Score:3)
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!
(To be fair, a more interesting statistic would be the percent of files in each language that contain ugly hacks.)
Re: (Score:2)
Nice one :o) Wish I had mod points.
Nonsense... (Score:5, Insightful)
Re: (Score:2)
Really? Not in my experience. Have been developing embedded software in C for money for 10 years now. The more years have passed, the stronger my dislike of C grew. It was ugly enough for the 1970ies, but using the same tools in 2015 is insane, I think. It is like using a slide rule instead of a TI-84.
Re: (Score:2)
Low hanging hack... (Score:5, Informative)
#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,
Re:Low hanging hack... (Score:5, Insightful)
Re: (Score:2)
Yup, they are trying to make portable code which is also efficient, and that's hard to do as pragmatics keep tripping you up. With a lot of other languages, the portability is generally easier because there are no compiler differences, no machine differences, no limited subsets available for smaller machines, or the community generally never worries about portability.
Examples of ugly hacks? (Score:2)
I for one would love to see some examples of such "ugly hacks", and also how it should/could be done in a not so ugly manner.
Heavy duplication (Score:4, Insightful)
Only meaningful if weighted (Score:5, Insightful)
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.
Define Ugly Hack (Score:4, Informative)
it's a C idiom (Score:5, Insightful)
Re: (Score:2)
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.
rotfl
Re: (Score:3)
Someone I know has a fast way to compute CRCs without tables that use only a single loop. The method seems broken to some people who want to see the traditional nested loops, and they insist that the code must be wrong and so it should be rewritten to be larger and slower. They probably think it's an "ugly hack". But when you do the math it all works out.
Stupid (Score:3)
Re: (Score:2)
Maxim 43: If it's stupid and it works, it's still stupid and you're lucky.
Credit goes to Schlock Mercenary [schlockmercenary.com].
Re: (Score:2)
Don't confuse this with being too stupid to understand how it works.
Re: (Score:2)
4k (Score:2)
How could "ugly hack" exist in perl code. Every single line ever written is an elegant beautiful hack, by design.
Re: (Score:2)
Sponsored video?! (Score:2)
Is it time for me to finally tick the "Disable Advertising" checkbox?
Self selecting? (Score:2)
Because C is so sparse and clean (or primitive, ymmv!), and people using C tend to be more experienced (almost nobody starts with C anymore - you use it because the job needs it), I find C programmers are a lot more likely to recognize things as ugly hacks and label them. It's partly defensive, because other C programmers are also old and cranky, so you're tagging it with YES I KNOW don't start with me. You don't want to check this in and have, say, Linus think you don't realize compromises were required.
O
Comments are subjective (Score:2)
Which makes this all subjective. There are already comments by people who say that anything not done in C is ugly, so how to tell that these same people didn't pepper other's code with that statement? Many people think code is an ugly hack merely because it wasn't done the way they would code it.
I've seen code written with procedures named for Alice in Wonderland characters and activities. Yet, I've seen that kind of thing defended here as 'creative'. 'Ugly hack' in a comment is a worthless indicator.
Of course it has the most ugly hacks (Score:2)
And it has them for the same reason it has beautiful hacks:
The complete and utter lack of fucking memory management, forcing the development of such hacks.
Film at 11 (Score:2)
Coming up after the break, new insights into why dogs lick their balls.
Alternative interpretation - C beset peer reviewed (Score:2)
Honest (Score:2)
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 */.
Re: (Score:2)
Or have higher standards and identify their ugly hacks where others don't?
It just shows the self awareness of C coders (Score:4, Interesting)
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.
Re: (Score:2)
Re:Such is C (Score:5, Insightful)
C Code EVERYWHERE has the most "ugly hacks"
Ah, but C also has the most beautiful hacks.
Re: (Score:3)
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 :-)
Re: (Score:2)
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.
Reminds me of this monstrosity [wikipedia.org]. It's not two overlapping switch statements, but a switch entangled with a do ... while loop. If that sounds familiar, you may be able to find your code from the links in the External References section.
CJ
Re: (Score:2)
I remember something similar, called Duff's device [wikipedia.org]. 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 {
Re: (Score:2)
Tom Duff was working on very high speed rendering code for Lucasfilm when he found that.
Re: (Score:3)
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.
Re: (Score:3)
I mean, a lot of code is only meant for one platform type. Not writing code compatible with obsolete processors is no great sin.
Re: (Score:2)
True, but I don't think x86_64 is obsolete just yet...
Re: (Score:2)
Fair enough. 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. Either way, if you're writing code that you know is likely to break on a different architecture because of its unique characteristics, IMO, you should at least make it fail to build on any other arch
Re: Such is C (Score:5, Insightful)
Is that really something to brag about?
Yes. If you don't understand why, you have no place in engineering.
Re: (Score:3, Insightful)
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: (Score:3, Insightful)
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 do
Re: (Score:3)
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
Re: (Score:3)
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 star
Re:Such is C (Score:4, Insightful)
Wrapping it in ifdefs doesn't make it elegant. It just makes it not a hack. Instead, it makes it ugly, and correct.
Re: (Score:3)
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
Re:Such is C (Score:5, Interesting)
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).
Re: (Score:3)
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.
Re: (Score:3)
it's been the nom for so long
And it's everywhere, which makes it the om nom.
Re: (Score:3)
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.
Re:Such is C (Score:5, Insightful)
C code is ugly hacks. But how else are you going to write an efficient ring buffer?
Re:Such is C (Score:5, Informative)
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.
Re:Such is C (Score:4, Informative)
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.org], "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.
Re: (Score:3)
well, it turns out that they evaluated the ioccc repository.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
What an obscure description of Borland.
They wrote compilers for Windows shareware developers? Really? just Windows shareware developers?
It was the number one Microsoft platform C/C++ compiler through the 80s into the mid-90s. It had nothing to do with Windows, or Shareware through most of it's life, and the company still exists even if it is a shadow of it's former self.
I don't recall Borland C++ or Turbo C++ ever forcing use of .hpp files or similar though, I always stuck to .h. I've seen .hpp in various p