Personally I use the following convention for tables and views: Prefix the table name with the type of data it holds, which is usually pretty clear, but no t always. Here are some examples of the prefixes I use:
data_ (Tables that hold core data)
ref_ (Reference tables that hold look-up values)
xref_ (Many-to-many join tables)
info_ (Meta data tables (may not apply in some situations, but in my case, stuff like tables that hold data about which versions of associated data or applications the database goes with, etc.))
app_ (Tables that are appended to other tables via views (Again may not apply to a lot of people, but in my case these are static tables that hold stuff like geographic information, which is appended to records by stuff like zip code, etc.)
and of course, the widely used fact_ and dim_ prefixes for facts and dimensions in data warehouses.
One could argue that such prefixes should now be implemented as schemas, but I like to reserve the schema for "who", as they provide a different level of security management.
Where I currently work we use all lower case for column names, and Mixed case, with underscore separators for table names, so like: data_Claim_Transactions.
We use all lower case for the column names in part due to the fact that we have a mix of Java and Linux, which are case sensitive. Also, since Oracle is case sensitive, I think even if you are using SQL Server, which isn't by default, its a good practice to design for case sensitivity. We use quite long column names actually, we have some around 100 characters long, but they are very descriptive, and given the nature of what we do, its kind of required. I'd say for an application database, you can get away with shorter column names. In data warehousing, you tend to need longer names, especially when you have lots of columns with similar content or if you have highly denormalized tables.