Hacker News Reader

Comment by bambax | Hacker News Reader

This 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".

But this statement seems the most interesting: "By comparing advanced and less advanced programmers’, we found that more advanced programmers are easier to de-anonymize and they have a more distinct coding style."

Beginners tend to think alike, while experts develop an original line of thinking, that is identifiable. The paper could be called "Fingerprints of Thought"...

View on HN

Beginners tend to think alike, while experts develop an original line of thinking, that is identifiable.

I'm not sure I agree with your conclusion. Beginners tend to look to others' code more frequently (often including copying and pasting), which means their "style" is really an amalgamation of multiple styles.

On the other hand, even when more experienced programmers look to others' code, they will still fold it into their own style, even when including large amounts of somebody else's code. Their own style shows through the entire project.

However, both of us are just hypothesizing. A great follow-up to this work would be to look at why beginners are harder to identify. I'm sure the other obvious follow up, "how to anonymize yourself", is in the works somewhere.

The other thing I'd be interested in is how well this holds up for multi-person projects. Would it be possible to identify if I submitted code to the Tor project? How much do I have to contribute before identification becomes likely.

Given the goal, that still counts as style. That thought patterns are reflected in code just makes it easier to tell who wrote it.

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.

Writing code that is plain, unsurprising, and reproducible not only is, itself, a style but also still leaves a lot of room for creativity/individuality.

Writing code is some ways a lot like writing in general. From the "elements of style" book:

> Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that he make every word tell.

https://en.wikipedia.org/wiki/The_Elements_of_Style

Concise sure, but at the very least reasonably easily decipherable and preferably readable.

There's always more than one way to skin a cat in these things, we're talking about choices much deeper than where one puts their curly braces. For projects I work on I can guess with a high degree of certainty who wrote what just based on general patterns, naming conventions, phrasing in comments, etc. Most of these could be called "plain and unsurprising and reproducible" but people tend to leave little fingerprints here and there.

Is this view unique towards programmers or do you extend it to artists and writers as well?

Artists and writers' products are supposed to be aesthetic; code is supposed to be readable and maintainable.

I apply it to journalism, though. Newspapers have long had "house" style guides to keep things consistent across reporters.

Call it a best practice for inexperienced artists and writers. If I, for instance, were to take up painting as a hobby, I would try to find some artistic formula or method to follow before branching out into a more unique style.

I would consider this more important for writing than art, since reading novels involves much more of a time commitment from your audiences to appreciate, whereas art gives more flexibility in deciding how long your audience wants to spend with it.

However, there's a difference between bad art and writing and bad programming. Bad art and writing lacks appreciation. Bad programming is full of errors, hard to maintain, and runs slow, giving an overall poor user experience.

Artists and writers don't usually make things that will be modified in the future. Art also faces less risk of dependency hell.

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.

Totally agree, in the paper they only look at competitive programming contests. Ideally, it would be interesting if the same could be applied to a larger code base with more authors and if it's possible to find a particular author in such a code base.

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.

The original "design patterns" book, where the term comes from, talks exactly about that.

Why don't you consider different approaches and algorithms a part of definition of style?

It doesn't seem to be the primary meaning of the word; style is considered superficial, a coating over substance.

Of course that's a matter of interpretation, but I find the summary of the paper suffers from the ambiguity.

There is also the fact, that I alluded to, that winning entries in a programming contest should be more alike than non-winning entries, in that they all actually solve the problem; if non-winning entries were included, it could explain some of the discrepancy in identification success.

I think the correct logic is more like this: Because the winning entries are all solving the same problem, any discrepancies in how they solved it (logically or stylistically) are magnified when grouped together.

Reply on news.ycombinator.com