I would say it is inconsiderate. Editor settings shouldn’t have an impact on the compiled executable (except for cases where editor settings affect things such as multi-line string literals). I chose the editor settings that I have because I like them that way. If I check out a code file and suddenly my editor behaves in a manner that I am not used to, I am not going be happy at all. How would you feel in a similar situation, if my unfamiliar editor settings suddently overrode yours?

I think if you want to check in editor settings, the best thing would be to have them in a separate file and make it very clear that the file will change the user’s current editor settings, and that it is optional to use this file.

If you are concerned about new individuals following an established group standard for code formatting, you can ask everyone to format the code according to the standard on check-in. I think some source control systems might support such an auto-format automatically, but I’m not sure.

This is very useful in cases such as where your standard practice is spaces isntead of tabs, but then one type of file (say a Makefile) requires tabs. I wouldn’t use it to force my personal editor preferences on other people though. As long as your code doesn’t require weird settings, which it shouldn’t, then other people can look after themselves when it comes to their editor settings.

I never thought about it, but I’d say:

• Things which should always be the same for this file, it’s good (but unusual) to specify within the file. Eg. most projects should have a guidelines that files always use spaces, or always use tabs, so if that’s specified in the file it can only help.

• Anything that’s a personal preference for developers should NOT be in a shared file. It doesn’t matter how much developer A likes auto-indent, she/he doesn’t know whether other people don’t like it or have a good reason not to use it. But don’t make a big stink, just remove it and/or ask developer A if it’s ok — they may well not have noticed.

• It’s unlikely, but if developer A genuinely wants different settings for different files and developer B doesn’t they need to talk to each other and come to a compromise that lets them both get want they want. They may not have realised there’s a problem.

For files that uses a non-standard extension to represent its purpose (e.g., .dat or .inc) even though it is largely written in a particular programming language, then it is useful to be able to mark the file type to be the programming language so that the syntax highlighting can be an aid when editing the input data. For such generic extensions, it is often the case that different files with the same extension may each contain “data” written for different programming languages. For example, simple code generators.

You could work around this by renaming the file in such a way to make it clear the file was actually data input somehow, but give it the expected extension. Or by defining new extensions.

There aren’t really any other settings that I think are relevant for the purpose of being embedded within the file that cannot be more conveniently handled in some other way outside of the file.