Actually filenaming conventions are the topic of much debate in many circles. Anyone who has worked on a project with fellow programmers, sysadmins, etc... knows this problem well. Anyone who has ever taken a position in a company that's been around for any length of time is usually even more familiar with the problem. Given that Unices today support long filenames vie with that the user slant for wanting to type as little as possible and you run into some interesting combinations. For example I work for a telecommunications company that has been through many generations of sysadmins, many of who know perl. These files have been called:
(I know, I thought it was a shell script too)

One can see the confusion that this would cause when you (for example) upgrade perl/a perl module and want to make sure nothing is going to break (although perl is pretty good about backwards compatibility).

Unices allow a lot of freedom in filenaming and for the most part this is a good thing. It is important, however, to apply a bit of common sense to your filenames The DOS legacy of many of todays administrators places that trend toward the name.type format, and I think it works rather well.
perl files =
text files = name.txt
C shell files = name.csh
Korn shell files = name.ksh
you get the idea.

Please never name a file "core" or "junk", or I will have no pity when you find your files deleted, restore will not be an option.