naming conventions are just that...conventions
it doesn't really matter whether you use columnname_id or columnameid or ColumnNamID.
I uised to use _ as a separator for things like ID, these days I tend to find ColumnNameID is the more common convention, so I tend to use that.
providing its consistent and applicable to all code developed in that shop. there's nowt worse in my books in finding multiple conventions in one site, and undoubtedly its easier if everyone used the same convention
AFIAK the old style syntax is deprecated and join is the preferred syntax.
personally I find it easier with newbies to get them to think in terms of blocks within SQL .. the JOIN being the 'proper' place to define relationships, the WHERE the filter, and so on. but Im not prescriptive...
AS the JOIN syntax is the current preferred syntax Id rather start people using JOIN rather than WHERE..... I think its fine for people who are familiar with WHERE or for legacy code, it may not be a smart choice for current or proposed applications. Whether the WHERE join syntax will ever be phased out is a moot point, but in my books its no reason to start people off using it.
The JOIN syntax makes more logical sense to me, it also is more capable, and perhaps more importantly more transparent than burying the joins in a WHERE clause.. that transparency has more to do with the legibility rather than the familiarity of "that's the way I've always done it".
Im currently paying some of the pain of moving into a .NET environment, and hating it, because I can't use the old styles that I'm familiar with. Id like to continue to using the familiarity of
VB but instead Ive got to relearn .NET.. its a pain but it has to be done