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. – Benjamin Bannier Sep 7 '12 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). – Carlos Campderrós Sep 7 '12 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. – Benjamin Bannier Sep 7 '12 at 15:35

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.

  • You made a great point about special files like Makefile, haven't think of it. – Carlos Campderrós Sep 10 '12 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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