Finally some serious stuff.
Facebook: Your code sucks, and we don't even have to run it to tell
Facebook has released the source code to Infer, its static analysis tool, under the open source BSD license. Static analysis tools like Infer are used as a complement to traditional dynamic software testing by scanning the source code of software to spot trouble spots without actually executing the code. In a Thursday blog …
COMMENTS
-
-
Friday 12th June 2015 11:38 GMT DanDanDan
Re: 1% Finished?
That's kinda the point of Open Source. We all (developers) need a good tool to check our code, so let's *all* work together on it to share the resource investment so we can *all* benefit. I like it. What's your criticism? They've done 1%, now all we need is another 99 companies to come along and work on it and it'll be done. I don't think that's unfair.
-
-
-
Thursday 11th June 2015 23:57 GMT Destroy All Monsters
That's a bug that is not apparent, for example a null-pointer exception that has not manifested yet. It generally indicates the use of imperative languages firmly rooted in the 60s, scant knowledge of development hygiene and/or the presence of hot-shot programmers who are actually too green to know what they are doing.
-
Monday 15th June 2015 14:58 GMT Michael Wojcik
Well, you can have a "potential bug" if you have a code path containing an invalid operation that's not reachable in the system as it now exists, but could be made reachable by a future change, for example. I see a lot of these in real-world code, particularly in rarely-exercised branches like error handling for failure modes that are difficult to reproduce. You can also find them in partly-implemented features that aren't enabled yet and so forth.
Another example is code that relies on unspecified behavior which may change, e.g. due to a toolchain upgrade or changes in build configuration. Use of uninitialized variables in C programs is a typical example - often the actual run-time behavior will be different in "debug" and "optimized" builds.
One of the benefits of static analysis (over dynamic analysis1) is that it can identify possible bugs in such dormant code, before they're activated by changes during maintenance and enhancement.
1Which of course has its own advantages over static analysis.
-
-
-
Friday 12th June 2015 00:33 GMT streaky
Re: Nothing like reinventing the wheel...
Assuming that the existing tools are actually fit for purpose much? It's surprising how sometimes you start with a tool; thinking you're gonna modify it to be better and end up just starting from scratch because what's there is either crap or you can't get it to do what you want.
Then again even when you do some projects pointedly refuse to accept submissions.
-
Monday 15th June 2015 15:05 GMT Michael Wojcik
Re: Nothing like reinventing the wheel...
Even the fastest static-code analyzers for C-family procedural languages can't offer the kind of speed Facebook is claiming for Infer on large code bases. That's rather the point of what they're claiming as innovative (separation logic and bi-abduction; read the materials linked in the article). Static checkers like cppcheck are plenty fast enough for a separate check stage, but not really fast enough for continuous near-real-time operation while programmers are writing code. Infer might be.
Personally, I'm not terribly fond of real-time error detection in the IDE while I'm writing code, but a lot of developers seem to like it. So that appears to be fairly novel and valuable to some people.
And Findbugs is for Java, and PMD only does source analysis on Java, Javascript, and a few other targets, so they're really not comparable anyway. Splint or cppcheck would have been better examples.
-
-
Friday 12th June 2015 01:37 GMT Terafirma-NZ
And yet the app still continues to jump to the top halfway through reading something because there is a new post.
Having a tool like this shows that it must be a group of teenagers writing code and some poor devs got sick of fixing the same problems over and over again I mean you wouldn't build a tool like this if every bug was new and unique but rather because the same issues kept being repeated.
-
This post has been deleted by its author
-
Friday 12th June 2015 08:25 GMT Michael H.F. Wilkinson
And once they add the GPP* feature to it
it might commit hara-kiri on seeing some of the code I have had to grade, and, to be brutally honest, have written at some points in time. Scientific code is often VERY ugly (but, hey, the article is documentation enough, isn't it? ;-) )
*GPP: Genuine People Personality is a registered trademark of Sirius Cybernetics. Please only use after clearance with the Sirius Cybernetics Complaints Division. Share and Enjoy!!
-
Friday 12th June 2015 11:16 GMT DNTP
Scientific code is often VERY ugly
This is true as heck and I am one of those scientists horribly guilty of this. Code written for a one-off project? Yup. That's completely undocumented? Check. That somehow gets migrated onto the pipeline server as a shortcut for other people who don't know ANY programming? Obviously.
Hello world, I'm sorry for doing this but there was no other way (except hand annotating result tables with tens of thousands of lines).
-
Monday 15th June 2015 15:12 GMT Michael Wojcik
Re: Scientific code is often VERY ugly
I'll let you in on a secret: business code is often very ugly, too. There might be a lower incidence of one-off programs that end up reused after all, but all the other ills of poorly-written software are common.
Writing maintainable software is in some respects like every other sort of writing: doing it well means a lot of additional work, including organizing, drafting, rewriting (anathema to many programmers), and so on. In fact, you can take many models for the text-writing process, or similar models such as Aristotle's rhetorical canons, and find close equivalents for aspects of creating maintainable software.
In other ways, of course, writing software is very different from writing prose. But programmers often forget that when they write software, they're writing for two audiences - machine and human - and neglect the latter.
-
-
-
Friday 12th June 2015 08:37 GMT Olius
"Please do our homework for us"
This is very funny...
"Facebook says it's releasing Infer as an open source project now in hopes that community participation will help it advance the tool beyond its current state, which its engineers describe as "1 per cent finished." "
Translation - "We tried to reinvent the wheel without realising how hard this problem is to solve and we got the the end of our knowledge on the subject. Help?"
-
-
Monday 15th June 2015 15:54 GMT Olius
Re: "Please do our homework for us"
You're right, I didn't read them. I was making a funny from the fact that the article states that there are several more complete, though slower, tools out there for this (hence they are reinventing the wheel) and that facebook themselves admit that this tool is only 1% complete (implying they are trying to reinvent an incredible complex wheel)
-
-
-
Friday 12th June 2015 10:00 GMT Doctor_Wibble
It's all true!
You don't have to run code to know if there are bugs in it. If there's more than around ten lines of code, it has bugs.
Job done, you're welcome, please deliver my £64,000 consultancy fee in small notes via wheelbarrow and preferebly during a light breeze for maximum effect.
Beer icon, because that's what money is for. And pies.
And chips, followed by coffee and cake to make my five-a-day.
-
Saturday 13th June 2015 09:53 GMT Christian Berger
There would be a very simple metric
Just count the number of lines/characters/syntax elements between matching ends of a "block". This block can be defined by matching brackets, or implicit brackets.
So something like if (k==0) {dosomething();}; would lead to something like 3 syntax elements for the first brackets and one syntax element for the second set. (alternatively you could count characters which is less precise but way simpler)
This way the more local your code is, the lower the numbers which correlates nicely with readability.
Of course this makes no statement about actual bugs in the code. However bugs are much easier to find in readable code than they are in unreadable code. Plus this is so simple that editors could include it to evaluate your code as you type.