On 2010-06-10, at 9:07 PM, Maxime Chevalier-Boisvert wrote:
As a compromise to what? Is this a technical compromise or a political one? I'm all for technical compromises which can be argued on their objective merits, but political compromises make me feel uneasy. Coding style has some aspects which can be evaluated objectively, but for the most part it is a question of taste and thus depends on the people in contact with it (i.e. the programmers).
It's both. My experiments with JS and JsDoc lead me to conclude that we should probably avoid using objects as namespaces for now, for technical reasons. They simply aren't proper namespaces. Once JavaScript gets proper namespaces, we might want to look into them, but right now, we pretty much would need to use hacks to make it work.
It's also a political compromise because, as you say, coding style is a matter of taste. Everyone has their own taste, but we want to pick some kind of convention and have everyone use it.
I'm not a big fan of CamelCase. I find it hard to read and the rules can lead to inconsistencies (should is_ASCII_EOF be mapped to isAsciiEOF or isAsciiEof or isASCIIEOF?).
I suppose this issue should also be treated in our conventions document. I would personally go with isAsciiEof. Capital at the beginning of each word/lexical unit.
There is also the issue of whether class names should be preceded by a module name, e.g.: ir_InstructionFoo or just InstructionFoo.
So I'm not quite sure what to do with this issue. We can bring it up for a vote among us after some more discussion. For the time being each one should just use the notation that they are most comfortable with. We'll refactor if need be. At this point what is important is that we advance the implementation... i.e. code!
Erick and I would like to propose that perhaps you should let us two take the final decisions as to the coding conventions and source code organizagion. Simply because those things are subjective, and we will be the ones who end up spending the most time working with this codebase.
We would rather spend time discussing with more objective technical issues, like the layout of stack frames and objects. However, perhaps it should simply be agreed that once Erick and I have spent a little more time working with the codebase, we will decide on the conventions we find more practical, to be used by all contributors.
- Maxime