From time to time I find projects with completely inconsistent naming for their items. While I believe naming things – be them source code files, variables, or enum values – is one of the most important things for the long term.
Yes, I know. For files, path length is imporant, so sometimes you cannot assign them very long names. But do name a service ComputingService instead of just Computing even if you put it into a Services namespace (folder). Still, don’t fall into the other extreme: do not prefix an item with all the namespace path from the project root. Indeed, it wouldn’t be fun to call it PublicApiSpecializedComputingService.
Another thing I want to mention here is about grouping files in project folders. While it’s fine to do it, mind the path length and do not group by multiple criteria in the same root folder. Create more sub-root folders for criteria separation, otherwise it will be strange in most IDEs. For example, have Services split into Infrastructure and Logic first, then each into Generic and Specific, if needed. I wouldn’t like a root folder with specialized logic services directly inside, and Infrastructure and Generic subfolders (and another Generic within Infrastructure) outside.
And do create Contracts folders for grouping interfaces, especially if they use hungarian notation and always start with an I: otherwise these files will end between implementation files when sorting alphabetically and most IDEs don’t even support other types of ordering for the files of a folder!
You could argue that you don’t need a Contracts folder when you have a single implementation file in the same folder with the interface, but even then sorting items in different folders may lead to inconsistent ordering and sometimes the interface would be the first, and other times the last. So I’d say it’s best to always separate contracts, even when it’s only one! You may want to even put them into different assemblies, as it would be a lot better that way if you’ll be using the (almost always mandatory) dependency injection pattern!
Finally, use var or a similar generic keyword for introducing a field or local value indicating that its type should be automatically inferred whenever it’s clear from the name but think twice otherwise. Note that to be able to reach this condition, a variable name should really fit its content, expressing as much as possible about its usage. For example, in my opinion a lagInMilliseconds field can be of type double without specifying the type, and so could be, of course, a startDateTime value of type DateTime. But don’t call the output variable of a Linq query just result or tuples: find out and use the meaning of the value since there its type would be too complex to indicate and wouldn’t clarify anything anyway, even when it’s just an intermediary step in a larger algorithm!