Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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
add comment

3 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
You made a great point about special files like Makefile, haven't think of it. –  Carlos Campderrós Sep 10 '12 at 8:10
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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