I don't know that there is really any "best" naming convention out there, as it really boils down to personal preference and ease of development. My advice is to pick a naming convention and adhere to it. If you wish to separate words with an underscore, do so in all of your database objects. If you wish to use camelCase, do so in all of your database objects.
In my shop we adhere to the following rules:
We separate words with underscores and use all lower-case letters.
Our table names describe what they are: dbo.person, dbo.invoice.
Our many-to-many table names also describe what they are (with the addition of mm to indicate a many to many relationship being mapped: dbo.person_mm_address.
Our user-defined stored procedures describe both the object and the action being performed: usp_person_select, usp_address_select_by_city
Our views and functions follow the same rules as stored procedures.
Our indexes include table, key columns (in order), and an indication of clustered/non-clustered: ix_person_last_name_first_name_nc
Just because this is what we use in my shop, it doesn't mean these rules are right for you. Pick something that you and your development team agree is both useful and easy to develop with, and establish a culture of knowing and using whatever naming convention you decide upon. In our case, this includes code review for any objects created in a database. Over time, the combination of a documented naming convention and peer code review has led to fewer and fewer deviations from convention.
I hope this "non-answer" helps in some way.