The success of a project can be judged not only by the timely delivery of working code but also by other factors such as:
How much of the code is covered by tests
How well organized the codebase is (in a proper folder structure)
How consistent the naming convention is
How easy it is for someone who is new to the project to understand the code
The naming conventions and many other factors are a matter of personal taste. However, for the sake of consistency, it's always advisable to agree on certain naming conventions and best practices to be followed for any important projects.
As discussed in Appendix A, Yeoman, tools such as Yeoman (http://yeoman.io/) help with the scaffolding and setting up of the initial folder structure. Similarly, code beautifiers available in various IDEs help in arranging the code in a single file to follow accepted norms with spaces, tabs, new lines, and so on.
You've got a taste of some of the naming conventions that I've followed in the preceding examples. For example, the template file has been named with a .tpl.html extension. Similarly, a controller file is named with a .ctl.js extension. Although it's a trivial change, it adds a lot to the overall code readability. Similarly, the names of the controllers starts with a capital letter (EmployeeCtrl), whereas the names of all other components start with a small letter (collectionBindingApp).
Yeoman organizes the code by type, that is, it has folders for controllers, views, services, and so on. This is OK at the beginning but has a distinct disadvantage: the files that logically belong together to a feature, that is, a view, a controller, and various services the controller needs, are in different folders. So, it becomes difficult to locate these files. When you are working on a particular feature, you are going to need these files at the same time.
So, the other option is to organize the code by feature or by component. So, assuming that your project deals with employees, departments, and so on, there will be folders named employees or departments. Views, controllers, services, and directives belonging to a component live in the particular component's folder.
You may refer to the following links for more details on organizing the Angular code:
AngularJS style guide at https://github.com/mgechev/angularjs-style-guide
AngularJS best practices at https://github.com/GrumpyWizards/Angular
Best practices recommendations for Angular App structure at https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub
The Google JavaScript style guide at http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml; this is a good place for general JavaScript conventions
Check out AngularJS Batarang (https://chrome.google.com/webstore/detail/angularjs-batarang/ighdmehidhipcmcojjgiloacoafjmpfk?hl=en), a Chrome extension. This helps in debugging JavaScript applications written using AngularJS. It gets added as an extra AngularJS tab in the developer tools where it shows different scopes and models. We can check which models are attached to which scope.
Also, check out Built with AngularJS (https://builtwith.angularjs.org/) for interesting examples of sites/applications built using AngularJS.