Rubbish. Style has to do with habits picked up along the way. Nothing more nothing else. Stop with the psuedo science. When programming in the large (Enterprise). My style is Javaish very long names reactivateSuspendedUser().

When coding for myself, I prefer snake case to camel case and shorter variable names.

Likewise in code, For work, I abstract and decouple to keep the code open for future updates. For personal code, I write throwaway code. Given 2 classes that I have developed for work or play. You will not be able to tell it's from the same person.

I think you're too quick to dismiss. All that your examples prove is that your personal preferences are different to business style code. The fact that you prefer snake case, shorter variable names and throwaway code is quite telling; I enjoy programming puzzles like Advent of Code, and I always use long names in camel case and try to never repeat code. I find that it reduces the mental load and allows me to confidently code faster.

Also it's not pseudo-science. There are real, live techniques for identifying programmers based on binaries:

https://arxiv.org/pdf/1512.08546.pdf

Identifying programmers based on their style is different than assuming people with a certain style exhibit certain personality traits. Programmer A and Programmer B could have almost identical styles, but that doesn't mean they have similar personalities.

Fair point, but I still think the comment I replied to was too quick to dismiss. Especially the last sentence.

You're taking this too seriously. This is not even pseudo science. Just Pseudo.

Yeah, I'd go further and say that preferences only should come into play early in a project when you're deciding on what the style of the project should be. For most of the lifetime of a project, writing in a style that is uniform with the rest of the codebase should come before your personal style.

This sounds like it's gearing up to some Myers Briggs or Learning Styles garbage. I don't think you'll get very far with correlating personalities with code. I think you might be able to learn some temporary behavioral traits by studying code, but nothing like a "personality".

Can you give some examples of how personality traits manifest themselves in code?

That sounds kind of fun, can you give some examples?

Maybe not exactly, but this was recently in the news:

"De-anonymizing programmers from executable binaries"

https://news.ycombinator.com/item?id=16598962

It's quite hard to examplify once I actually think about an example, but I'll try. It's more a global vibe of a piece of code rather then semantics but they do play a part (using Python as example):

A young person (say 24), has experience coding of a few years, but very enthusiastic, loves reading programming blogs, a real stickler of doing it the "right" way, and sometimes forgets other people might have to read their code. They are not as pragmatic as they would be 10 years down the road. They would use vim or emacs in vim mode because that's more pro. Their code might have a good few "clever" one liners that do something complex in a very concise manner. Took a while to compress into a single line and will take a week to read back and understand. Clever, but only if it never breaks or never needs maintenance. They write factories, sometimes of factories. They have 110% test coverage, including trivial stuff that doesn't require it. They would refactor a piece of code many times until it feels it's the right shade of clever. I like these coders because I can learn something from them, but if you have tight deadlines they might actually get in the way. Great to have a couple of these in your car, but don't let them drive.

    from itertools import chain
    first_set = set(['one', 'two']).union(set(chain.from_iterable([next.key for next in some_yielding_iter()])))
    other_value = make_value_factory_factory(first_set).make_value_factory()

10 years down the line these guys realise you write code once and it's read many times over, and the above turns into a more vanilla multi line readable expression of the same idea.

A less enthusiastic version of said 24 year old, codes because they knows how to, but has no aspirations to get better at their craft. Less organised individual. Pep8 is a new variation of Pepsi Cola? They are not bad coders, just sloppy. Their code works but can be better. They would benefit pairing with the above person.

    def someFunction(value):
        if (type(value) == ThisClass):
            processObject(value)
        elif (type(value) == str):
            processString(value)

After pairing, maybe they were inspired a bit. Maybe they refactor to this:

    from functools import singledispatch

    @singledispatch
    def process_value(value):
        process_object(value)

    @process_value.register(str)
    def _(value):
        process_string(value)

    def some_function(value):
        return process_value(value)

I think a good exercise is to look at a person you know and try ot match their personality to the code style. Then look at some code which might or might not be theirs and try to assert if it is.

I"ve been coding professionally for the last 12 years -- I'm 34 now -- and my code definitely still looks like example 2.

Maybe it's because I code in multiple languages daily, but I tend to not use a lot of the language features for each language. A part of it is definitely thinking about the ones that come after me, and wanting everyone -- from every background -- to be immediately able to reason about the code without having to look up what every syntax feature does.

I guess it's a fine line between depth of language features used vs. readability once one is gone from the project.

Its not an exact science, or even close to approximate. It's more for fun than anything else. The correlation between style and personality is 'loose'. And a lot of it is in the perspective of the observer and what he knows about the person upfront. I guess. Consider this a "fun" or "not fun" exercise, and nothing more :)

So what you're saying is that you guess and then rationalize your successes? (If the correlation is loose, you've really got to measure it to know for sure it even exists.)

I'm pretty much the same, been coding since 16 and I'm 28 now. I've gone through phases but I mostly code like the 2nd style. I mostly use JavaScript but occasionally pipe in another program (say python or C) when needed. I use new language features if it helps make things easier- ES6 has some really cool things, but I try not to let my code become cryptic. :)

Like another commenter on this thread, I too find the second example the most readable and I write code like the second example even though I have many years of experience with Python.

The third example is cool but I don't see the immediate value in writing code that way unless I am designing a framework of some kind.

I am of the opinion that code should be written in as simple manner as possible so that programmers from different background can get up-to-speed with the code with little trouble.

An OO language that has the ability to do dispatching on types ought to be exercised in that way.

Checking for the types explicitly in your code creates a brittle system. For a one-off bit of code, fine. For anything that may be extended in the future, it's a bad idea and will have to be refactored to become maintainable.

IMO, having functions that accept different types (when the types are unrelated) is an anti-pattern in most cases, it doesn't matter if you make it more "maintainable" by using single dispatch.

It's fine when you have related types, but in the example `someFunction` accepts both ThisClass and str, which (I assume) have very different functionality.

You see this anti-pattern a lot in dynamically-typed languages. As an example, both these examples are valid and do the same thing in `knex`, an SQL query builder for node:

    knex.select('name', 'email').from('users')
    knex.select(['name', 'email']).from('users')

Second is example is most readable, I agree. What I was trying to convey there was first the use of "type" vs "isinstance", and second the use of non pep8 snake case in Python which is frowned upon. Then I wanted to show there is another way of handling (larger) blocks of "if this type/instance then this, if that then that, etc.". I use it as a getter when I have either an id or an instance and it feels smoother to me. Python's version of overridden methods. Both are fine of course.

I'm not trying to start an offtopic discussion, but the not enthusiastic 24-year old looks like the clearest and best option to me. Personally, I would refactor it to three lines.

Except grabbing types like that in code is usually a code smell. It can become brittle and hard to extend as time goes on. It's suitable when you need something now or you know you'll only ever have a few (less than 4 or 5, preferably no more than 2) cases. But either way you ought to be refactoring to something more like the third example.

Well, calling type() is usually bad, isinstance() is a little better. But if you're expecting a ThisClass and only falling back on strings, as implied by the example, surely this is the classic example of where duck typing is handy:

    try:
        processObject(value)
    except ValueError:
        processString(value)        

Where you've written processObject so that it only works on duck-like objects:

    def processObject(value):
        try:
            value.quack()
        except AttributeError:
            raise ValueError('I was expecting something like a duck!')

Personally, I consider code I don't understand after reading it thrice a much worse code smell.

Less sarcastically: I think you're being too dogmatic. I don't like the idea of 'code smells', because it encourages you to judge code not by performance, maintainability, or readability, but by the property that someone has decided it's a code smell. Often it's true that the pattern can be used to write utterly shit code. Code smells are, IMHO, being used as a substitute for common sense. My common sense tells me that the first example is most clean solution. If the code keeps you from obtaining the performance you need, or if you add more checks in other places which make the code unreadable, by all means, refactor it.

Interesting example to give. I always think it's good to have programmers with quite in-depth knowledge, and programmers who are more superficial in their programming knowledge but get stuff done.

In my experience, it's not so much about age, hence I'm not sure if that is relevant in there. (For example, I'm not sure if using VIM is something younger programmers tend to learn, and I'd guess more of the 'older generation' will know it).

Yeah age is not relevant really, but I went for a complete example. As for vim, or emacs in particular, I actually met a few of these 20 something programmers with enthusiasm who went there. Some stayed, some came back frightened. But they all tried (and I modelled the exampled on them)

I fail to see how this relates more to a person's individual personality than programming habits or attitude. It's not unreasonable to see two programmers of different skill levels producing the same code simply because they're both showing up to collect a paycheck. It wouldn't matter if one is a perfectionist, depressed, hyperactive, high-strung, lazy or proactive. I'm relatively sure code style is tied more to experience rather than personality.