For class Foo, what is the rationale for calling the physical code module something different e.g. FooBar.cs
Is this just a style thing, or does it serve some other purpose/intent?
It is accepted that partial classes are a special case as these, by definition, exist in different files that must have different file names. Historically, these were heavily used for WinForms but can be used to avoid huge code modules that would otherwise be hidden away in code regions.
Generally speaking, these should be the same. The good practice standard is that every file contains exactly one class/interface/... and thus it makes sense to name the file after that one class/interface/... This is exactly why Visual Studio offers to rename the class when you rename the file (if the class and file name were the same).
That being said, exceptions do exist, but they are contextual considerations and are open to subjective discussion. Some people will refute any exception and will religiously stick to the good practice standard as a matter of style. Others will allow for reasonable exception. I'm in the latter group, and I'm just listing reasonable exceptions that I've encountered:
That being said, it needs to be remarked that these exceptions are contextual and extremely rare.
It is accepted that partial classes are a special case as these, by definition, exists in different files that must have different file names.
Not quite "must". The multiple parts of a partial class can live in different directories, thus allowing for the same filename to be reused.
But overall, there are indeed cases where you do vary the filenames so you can highlight which part of the partial class each file addresses, e.g. MyPartialClass_generated.cs versus MyPartialClass.cs (which is the most common scenario for partial classes, in my experience)
Is this just a style thing, or does it serve some other purpose/intent?
There is no technical reason to do this (other than avoiding duplicate filenames in the same directory). It's usually a matter of logical inevitability (e.g. multiple classes in file) or a matter of human readability (like the underscore example I listed).
The convention is that the file should have the same name as the type. There is also the case where people want to put multiple types in a single file. Note that having types with different names in a single file is also against convention.
As you point out, the motivation for the name difference could be parts of a partial type. Even though you could place them in different directiories that goes against the convention of mapping namespaces into directories (however there are reasons to not do that, they are much rarer).
There is another exception I want to talk about: different number of generic parameters. If you have type with the same name, but different number of generic parameters, you got to either place them all in a single file, or you come up with names for the files for each one. This is usually resolved by appending the number of generic parameters to the type name.
However, the most probable reason why you got a mismatch between file and type name because the type was renamed but not the file. Some tools will ask you if you want to rename the file when you rename the type, others won't.
By the way, here is a suggestion: use "." as separator. For example multiple parts of a single class could be named like this: Class.something.cs where something could tell you what the file is about. For example it could be a conditional compilation constant, or the name of the method which overloads are in the file, or the name of a nested type that is in that file, or whatever. By the way, all tools I know of are OK with this. None of them complain about a mismatch between file name and type name. Note that Microsoft does this for the generated part of forms (Form1.Designer.cs).
