I know this is kind of a subjective question, but I'm curious if there's any good reason to place (or not place) editor settings inside code files. I'm thinking in vi modelines, but it is possible that this applies to other editors.

In short, a vi modeline is a line inside a file that tells vi how to behave (indent with spaces or tabs, set tabwidth to X, autoindent by default or not, ...) that is placed inside a comment, so it won't affect the program/compiler when running. In a .c file it could be similar to

// vim: noai:ts=4:sw=4

On one hand, I think this shouldn't be inside the file, as it is an editor setting and so belongs to an editor configuration file or property. On the other hand, for projects involving developers outside one company (that are not imposed an editor/settings) or collaborators on github/bitbucket/... it is an easy way to avoid breaking the code style (tabs vs spaces for example), but only for the ones that use that editor though.

I cannot see any powerful enough reason to decide for or against this practice, so I am in doubt of what to do.

  • This only makes sense if all committers use the same editor and forcing an editor on people is almost always an unproductive task. I use modelines for my personal projects though and am happy with that. Sep 7, 2012 at 14:02
  • But if I'm the owner of a project on github, some committers will send patches (or make pull requests) with spaces instead of tabs (or viceversa). If I add a vi modeline telling to use spaces (or tabs), some of those pull requests will come properly formatted (and lots of users don't notice if a code is indented with tabs or with four spaces, because have configured their editor to have a tab size of 4). Sep 7, 2012 at 15:29
  • But your solution works only for part of the contributors (e.g. Eclipse or Notepad ignore vim modelines). This is a social problem and you need to deal with it like that, e.g. with code review (not too hard with pull requests). It also probably helps to document your standards somewhere or generate a couple of config files for typical autoformatters with e.g. universalindentgui. Sep 7, 2012 at 15:35
  • 1
    The de facto standard way to specify editor settings these days is with a .editorconfig file Oct 14, 2019 at 14:11

4 Answers 4


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.

  • If not automatically converted via the source control system (because not everything will always be automatically convertable), code linters can at least fail builds when the code doesn't pass the predetermined coding style, if that is the route you wish to take.
    – Flater
    Oct 14, 2019 at 11:48

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.

  • You made a great point about special files like Makefile, haven't think of it. Sep 10, 2012 at 8:10

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.