# Is there a way to check whether two notebooks share the same variables?

When I code in Mathematica, I often re-use code from old notebooks which fulfilled a specific purpose; for example, one testing for soft matches in strings, or one that identifies outliers on a graph and their index in the list. My code is generally written in a modular fashion using functions, such that I am able to immediately apply the function in my old code to the new data that I have.

The trouble with re-using code is that the function names I use in the old code and in the current code that I am processing sometimes overlaps. This most commonly happens with short function names such as f within the main function, or function names such as g which could double as a physical constant g=9.81 ms-2. To avoid this, I try my best to code properly and give my functions names that are unlikely to be re-used.

However, I'm wondering whether there's a way to list all the functions/variables used in two separate notebooks and perhaps check the list of functions/variables for those used in both notebooks. These overlaps could then be resolved automatically (perhaps by appending a notebook1 and notebook2 at the end of those functions/variables), or, more elegantly in my opinion, by allowing the user to choose the option of replacing all the duplicates in one notebook by another name.

In this similar question, separating variables between multiple notebooks is discussed, but this wouldn't really work in my situation since I actually want both codes to run in the same environment. I'm sure that the answers to this question would really help those who are engaged in large coding projects and attempting to re-use old code.

-
It is an interesting question. But, I have a suggestion, have you considered offloading the code you wish to re-use to a package? This way you can encapsulate the variables, and eliminate conflicts. Generally speaking, I employ a rule of three: if I have to re-use code three times, it needs to be put into a package, generalizing it in the process, if need be. I ignored that with a project I worked on recently (for the sake of expediency), and now have to fix a bug in about ten different places. –  rcollyer Mar 26 at 14:22
@rcollyer - I'll look into that. Making packages seem a bit daunting for me for now; but then again, there was a time when I stopped reading code whenever I saw a @, @@ or /@. –  Vincent Tjeng Mar 26 at 14:38
The rule of 3 makes lots of sense. Still, packaging has a cost & tradeoffs. Mma can spoils us because one can so easily alter code. When I need to think thru a problem I fall into refactoring code - generalize, making it more concise, or just improving variable names. This seems to let my subconscious work on the more complicated problem & I get better code for it. But, I can fall down in having the discipline to apply such refactoring to packaged code. Getting the right level of abstraction so that packaged code can have a reasonable life expectancy presents an interesting challenge. –  Jagra Mar 26 at 15:16
@VincentTjeng if you want reusable code that can be easily maintained, packages are the way to go. It is not complicated. –  Yves Klett Mar 26 at 15:16
You know you can access variables from different contexts anywhere, by its full name. So Notebook1f` would work from notebook 2. –  Rojo Mar 26 at 16:31