Bill Roper (billroper) wrote,
Bill Roper

Thud, Thud, Thud (Redux)

So there's a fellow rearranging the project files at work. Now the way that Visual Studio works, you've got a global directory include path that you use for finding all of the libraries that are external to your project. You've also got project-specific include paths that affect only the project that you're working on.

I am now embroiled in a knock-down, drag-out argument as I try to explain why includes that are specific to the project that you're working on need to go in the project-specific include paths rather than in the global include path, since if you put them in the global include path they will affect other projects that may not want the benefit of your wisdom about what needs to be included. Yes, you have to put this information into each of the project files, but once you do put it in there, it doesn't just vanish. It's persistent, so you don't have to keep updating it.

The counter-argument appears to be "If I put it in the global settings, I only have to type it once."

Which is true.

Save for the fact that you've done it to all of the projects, whether they wanted your change or not.


It strikes me that the counter-argument is neither strong, nor correct.

Am I missing something here?
Tags: musings, work
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded