Re: [PATCH] diff-cache path restriction fix.

* Linus Torvalds <torvalds@osdl.org> wrote:

i'm quite sure it's related to ambiguity. The main problem for the human brain when reading code is ambiguity of expression - ambiguity triggers 'logic' areas of the brain, instead of the 'visual automation' portions of the brain. Like it or not, most of the code reading we do is all automatism, if we had to _think_ about the visual structure of the code we'd be much less effective.

The moment we fall out of automation (you go to the bathroom in the morning but the toothpaste is empty, or you are in the shop and the coffee area got moved to another place), we feel unease. Thinking during normally routine activities means problems, it means distraction, it meant larger reaction times in the jungle for millions of years, and that's why the built-in unease. Thinking generates unease _especially_ if you dont expect it and dont want it - even if you happen to be Albert Einstein or Linus Torvalds ;) [And it's way too easy to let the autopilot drive all the time - there are people who stop thinking in their childhood and autopilot through life.]

Coding styles are mostly there to reduce the syntactic ambiguities of computer languages (and hence reducing parsing complexity), and thus to make it easier for the human brain to parse them - and thus to give more brain capacity for the real thinking.

the other interesting question is, why do most coders pick the 'x < 1' variant? I'm quite sure that's due to most of us having learned coding via operators. It's "x := 1" and "x /= 2", where the mirror image is not valid - and we extend that expectation to ambiguous operators too. It's the more complex entitity (the variable) that we think about first, and then comes the less complex entity. But if someone has a strong math background (Junio?) then the "1 < x < 5" syntax could be the natural thing he got used to.

so as long as the actual expressions are used in an unambiguous way, it's fine and it's part of the coding style and it's all a matter of getting used to it. Junio's method is just as unambiguous. How quickly you can adopt to another coding style is directly related to how practiced you are at it, but it also depends on your fundamental abstraction abilities. The overwhelming majority of coders dont "switch" a coding style that easily, but e.g. people who maintain a large number of packages or use lots of languages are very good at it. You have the luxory to be able to read your own coding style all day so it's pretty natural to feel unease if something else comes along :)

	Ingo