@austincheney -- I do like the tips you suggested, as many of them have been mentioned in the YUI Theatre videos and several books. However, I don't think by simply following these good practices will you "reveal a pattern of code that is easy to reproduce, easy to extend, and easy to maintain". I've created applications following most, if not all of these good practices, but still have been left with an application that is hard to maintain and add new features. For example, I've created several modules on a page and later down the road I've realized that these modules need to communicate. As a result, I've called methods of Module B from Module A, resulting in tight coupling. I've found that using the Publish/Subscribe pattern eliminates this really well and provides a great architecture for the most part. I haven't seen any drawbacks yet, but I'm curious as to whether there is a better approach to structuring the JS of an application.
I am interested in the MVC pattern applied in JS like Backbone. How would you describe this pattern from a JS point of view? On Jul 12, 7:04 pm, austincheney <[email protected]> wrote: > > I didn't catch the reasoning behind using anonymous function expressions. Is > > it to ease refactoring in the future (when moving chunks of code around)? > > Three reasons. > > 1) The functions then become associated with named variables, and so > they are then consumed by my point #2. > > 2) JavaScript is written and read from left to right just like > English, so therefore a named variable is read before the word > "function". This increases understandability, in my opinion, by > making functions most prominently identifiable with a unique reference > opposed to being identified most prominently by the word "function". > Contrarily, identifying functions most prominently with the "function" > keyword allows for more rapid identification of functions apart from > other code, but provides no benefit when attempting to rapidly > identify one function apart from another. > > 3) By assigning functions to a variable instead of using a named > function reference you are eliminating hoisting. The standard > behavior in JavaScript at execution time is that all variables are > moved to the top of the most immediate function and all unassigned > functions are moved directly below those variables. This is hoisting, > which is entirely automated and provides no control of declaration > with reference to other declarations. Eliminating function hoisting > is a benefit, in my opinion, because now I can have more granular > control of assignment and alteration of variables in closure. I make > effective use of this granularity in my markup_beauty function within > the Pretty Diff code. One of my primary objectives is ease of > maintenance, and I do not believe there is anything easy about > variables in closure to functions that are hoisted apart from other > assignments and references. > > Austin Cheney, CISSPhttp://prettydiff.com/ -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
