Opinionated AngularJS styleguide for teams

.

> Resolve promises in router, defer controllers

Absolutely not,you want to display something while you query the server.using resolve will block the router and not display the next view up until the promise is fullfield or rejected.It's perfectly fine to limit the router to routing and not stuffing it with business logic.

> Project/file structure

Wrong again, group files by modules/features ,dont put 1 service per file or one controller per file.We are not writing java packages here, but javascript modules.

At least you admit it is opinionated ,but at lest half of your opinions shouldnt even be followed.

Finally, someone with opinion, so far most articles on the topic have been too soft in terms how an Angular app should be written and organised.

However there is one point I disagree with: files and folders should be organised per-feature/functionality, not Rails-like. When you have 40+ services, and 100+ of directives, it can become tedious to work on these separate files. That's why I recommend to put files that do common stuff together. For example we have auth folder that holds the service, a couple of directives (like for password inputs), all possible states (we use ui-Router) and controllers, in total 8 files: http://cl.ly/image/2o0Q1n1m2M32

Re: module method definitions: is the IIFE still required if you'd just put a named function in the call to .controller()? I try to avoid boilerplate (like IIFE's) whenever possible; vanilla AngularJS doesn't seem to require IIFE's in most cases when defining controllers as anonymous functions.

Similarly, this approach seems to require adding a block of comment-boilerplate so ng-annotate doesn't get confused; inlining it would avoid this.

I can see that particular method for module definitions taking up seven lines of extra boilerplate code vs just inlining the (named) function in the call to .controller(), and I'm not seeing any definitive advantages.

Style guides are nice for making code look consistent and pretty on the outside, but I think far too much emphasis is placed on them (maybe because I use Python), compared to app design. Style guidelines won't make the slightest difference if your data model is crap.

``Angular modules can be declared in various ways, either stored in a variable or using the getter syntax. Use the getter syntax at all times.''

It would have been nice to know the reasoning behind this. It does make minification marginally easier (but later on in the document, the DI notation is not used for $routeProvider which prevents minification from hapening anyhow), apart from that I fail to see any advantage to that approach.

I pretty much agree with all of these opinions in this styleguide. There are some subtle points unsaid in the formation of some these opinions which make them preferable in general.