In the Java world class names always start with a capital letter and are CamelCase. In angular I consider the functions that define a controller, service, or directive to be a class and use this naming convention. All other variables or functions should start with a lowercase letter and be camelCase. Folders and Files names should use snake_case and be in all lower case. With these standards the code won’t blend together, each piece will be distinct and already have some encoded hints as to what it is or does.
Another common mistake is to store everything to the $scope. But this is not a good practice as we can get additional information on how the variables are being used based on how they are stored and can be accessed. Just ask yourself if the new variable needs to be used by the user. Only store variables to the $scope that need to be used by the view and model, and thus used by the user. If you need a counting variable that is never going to be seen by the user then just create it using ‘var’ so it’s not on the $scope. Also avoid storing things on the $rootScope, if you need to share data between controllers you should be thinking of a service. And never store anything as a global, everything should have its place and be apart of a namespace. This will help in documenting and to ensure no one overwrites a variable.
Here is my preferred way to organize a class to quickly locate anything you need. I always place just one class in a file, no other classes or any other code around it. At the top I define and possibly initialize all of the variables or attributes used by the class. Next I define the constructors and following them are the getters and setters if needed. And after that are the rest of the public functions usually in an order of importance. Below is an example and when all files follow this design pattern everything becomes familiar and quick to locate.
// Class Name
// variables or attributes
// constructors (if needed)
// getters and setters (if needed)
// private class only functions
// common public functions
// less used public functions or helper functions
This is just one out of a million ways you could organize your code, but it definitely helps to have some sort of structure. Just make sure your entire team shares their inputs and agrees and you’ll be developing like a well oiled machine. Post in the comments what you like or don’t like about this organization scheme, and feel free to share some of your code organizing techniques.