This seems to indicate that modern optimizers still have a long way to go to be as effective as they could be, since broadly similar code even in different styles would end up with the same, most efficient end result(?)
When coding style survives compilation: De-anonymizing programmers from binaries
41–50 of 74 posts
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#42This statement seems debatable: " Since all the contestants implement the same functionality, the main difference between their samples is their coding style. " All the (winning) contestants implement the same functionality, yes, but with possibly wildly different approaches/algorithms, so the main difference between code samples is not just "style" but what could be called "general thinking in and around the problem…
Given the goal, that still counts as style. That thought patterns are reflected in code just makes it easier to tell who wrote it.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#43This seems to indicate that modern optimizers still have a long way to go to be as effective as they could be, since broadly similar code even in different styles would end up with the same, most efficient end result(?)
I think you're assuming there is one maximally efficient ASM product that can be known at compile time. The same program will work on different inputs, and it's possible that different ASM products will handle some inputs more efficiently than others.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#44Well, this puts a damper on my plan to create a secret identity on the internet under which I release software the way Banksy releases art. Unless I stop publicly writing software for a few years.
My suspicion is that most of these features wouldn't survive in an adversarial setting -- either by consciously changing your coding style or (better) using automated tools to rewrite your source code before compilation to alter the control flow structure (e.g., control flow flattening [1]). http://reverseengineering.stackexchange.com/questions/2221/w...
Another option would be safety in numbers. Take a large executable written by someone else and wear its dead code like its your own skin. Hiding your true self in there somewhere.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#45This seems to indicate that modern optimizers still have a long way to go to be as effective as they could be, since broadly similar code even in different styles would end up with the same, most efficient end result(?)
They did this with optimizations off:
The above mentioned executable binaries are compiled
without any compiler optimizations, which are options to
make binaries smaller and faster while transforming the
source code more than plain compilation. As a result,
compiler optimizations further normalize authorial style.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#46This statement seems debatable: " Since all the contestants implement the same functionality, the main difference between their samples is their coding style. " All the (winning) contestants implement the same functionality, yes, but with possibly wildly different approaches/algorithms, so the main difference between code samples is not just "style" but what could be called "general thinking in and around the problem…
As a professional, I tend to think a distinct coding style is bad. You should try to write a code that is plain and unsurprising and reproducible. To me, this study gives us another reason that we need a more uniform/standardized methodology and good education for the software industry.
One might argue that the things that could be taught as part of such a standardized methodology would either be extremely generic, or can and should be automated. "Design patterns" and "idioms" are definitely helpful and necessary for practical reasons, but to me they frequently seem like good candidates for automatization. Maybe in an ideal world, the parts of a solution that are "unique", i.e., not well-known and established, are even the only ones that should be required to be specified by a human.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#47This statement seems debatable: " Since all the contestants implement the same functionality, the main difference between their samples is their coding style. " All the (winning) contestants implement the same functionality, yes, but with possibly wildly different approaches/algorithms, so the main difference between code samples is not just "style" but what could be called "general thinking in and around the problem…
Why don't you consider different approaches and algorithms a part of definition of style?
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#48Earlier quoted context omitted.
As a professional, I tend to think a distinct coding style is bad. You should try to write a code that is plain and unsurprising and reproducible. To me, this study gives us another reason that we need a more uniform/standardized methodology and good education for the software industry.
One might argue that the things that could be taught as part of such a standardized methodology would either be extremely generic, or can and should be automated. "Design patterns" and "idioms" are definitely helpful and necessary for practical reasons, but to me they frequently seem like good candidates for automatization. Maybe in an ideal world, the parts of a solution that are "unique", i.e., not well-known and e…
The original "design patterns" book, where the term comes from, talks exactly about that.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#49Well, this puts a damper on my plan to create a secret identity on the internet under which I release software the way Banksy releases art. Unless I stop publicly writing software for a few years.
> I release software the way Banksy releases art.
It's pretty easy to vandalize a wiki tho.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#50This statement seems debatable: " Since all the contestants implement the same functionality, the main difference between their samples is their coding style. " All the (winning) contestants implement the same functionality, yes, but with possibly wildly different approaches/algorithms, so the main difference between code samples is not just "style" but what could be called "general thinking in and around the problem…
As a professional, I tend to think a distinct coding style is bad. You should try to write a code that is plain and unsurprising and reproducible. To me, this study gives us another reason that we need a more uniform/standardized methodology and good education for the software industry.
I think you present a false dichotomy.
A distinct coding style does not indicate that the code is surprising or difficult to follow.
A diversity of styles should help overall code quality in an organization because you get to pick and choose the 'best approach'* for a situation, and more importantly, learn from your peers.
* whatever that heuristic happens to be... probably unsurprising and reproduce-able for you. I'd say the heuristic for me is 'concise, read-ably correct'. I've always thought of programming as closer to writing mathematical/logical proofs than anything else. If I can eyeball a program and say 'yup, that does what claims it wants to do,' then it's good. I don't think that heuristic always holds up in practice, simply because successful code-bases blossom proportionally to their success.