"be spread across multiple lines for complex types (including all objects and arrays, no matter how simple" Also, it's not just me that's wishing to use camelCase for JS.
#Moodle style and javasecript in plain text editor code
You're proposing making it such that developers have to use a combination of camelCase and moodlecase in code which sits side-by-side to modify the same object. If you use a Moodle dialogue, you're really using a YUI Panel + YUI Widget + Moodle magic. With the nature of JS, we frequently have Moodle code sat right next to code changing YUI objects. Conversely, with YUI, every time you wish to change a setting for anything that YUI handles, you must use camelCase. Yes, we may use lots of libraries in PHP which follow this guidance, but most of those libraries are fairly abstracted away and we rarely deal with them. We use serveral third-party camelcase libraries in PHP too, and the world has not ended." Thanks Tim. We use serveral third-party camelcase libraries in PHP too, and the world has not ended.- Tim Hunt ( talk) 16:02, 16 October 2013 (WST) "You are going to have to work very hard to convince me this is a good idea. Andrew Nicols ( talk) 14:46, 16 October 2013 (WST) "Contrary to the standard Moodle coding style, we Andrew Nicols prefers to use camelCase for JavaScript." You are going to have to work very hard to convince me this is a good idea. "Contrary to the standard Moodle coding style, we prefer to use camelCase for JavaScript."Īgreed, this needs further discussion and clarification, but I feel it's one of the most important changes.
Some points I think we need voting/consensus on: Thankyou Andrew for working on this - it is sorely needed. The following is the current state of the Talk page for posterity and reference within this thread. There is a talk page for the document, but it would be easier to follow if any issues, suggestions, comments, or criticisms could be discussed in this thread instead so I'd ask that you not use that. For posterity, I'll include the comments to-date in that page in a reply to this forum post. I've tried to provide appropriate rationale for many of these proposed changes and it's now at a stage where I believe that it's ready for some early feedback from the community. This is also raised in MDLSITE-1774 and once the draft is complete, it will be approved (or rejected) in that issue. The draft document, which is still a work-in-progress, is available on the developer wiki at.
To that end, I've begun work on a new set of JavaScript coding guidelines for Moodle to try and create a codified set of rules, and guidelines for JavaScript development in Moodle. a variety of other miscellaneous reasons.integration with a range of different third-party libraries involved and.different technologies dealt with (e.g.
0 kommentar(er)
