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:
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.
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.
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.