As computer modeling and simulations become more common in all scientific fields, there is growing interest from some researchers to see the underlying code. If the computer code is not included as part of the publication, there can be a gap between the code and the results that can be a problem for fellow researchers. “A lot of times people do research with computer code, but what they publish is a result of that computer code,” says ASA and SSSA Fellow Dennis Timlin, a Research Soil Scientist with the USDA-ARS. “They may have to ask the author for the code, if the author is still around, or they might have to replicate [the development] themselves.” But replicating code is challenging without details about the variables and equations used within the model, which do not always make it into the methods of the paper. Viewing this lack of access and documentation as a potential problem, Timlin and colleagues published a paper in Agronomy Journal, titled “Proposed Standards for Peer-Reviewed Publication of Computer Code (https://doi.org/10.2134/agronj2015.0481),” which outlines how code can be treated as original research, including going through a peer review and publication process. Co-author Olaf David, with the Object Modeling System Laboratory at Colorado State University, likens it to the same process a researcher would go through when writing a paper. “You start with the very rough draft…. Then you go through some revisions, and you now have people looking at your paper. You get feedback. You smooth the edges and finally publish.” Having someone else look at the code may detect problems or places where further explanation of the code is necessary. The authors suggest that these code reviews and publications be separate from the publications that may rely upon the code developed to test a hypothesis. However, code publications may need to include documentation of the underlying theory of the model, depending on its complexity. The paper outlines what information would need to be contained when submitting code for peer review, including the purpose of the code (i.e., what it does), identification of the author and version, the input and output variables, a list of variables that can be changed (i.e., parameters), and any internal variables. The authors also address the use of comments as well as the inclusion of test data and drivers. As part of this process, the authors propose that code be broken up into modules, pieces of code that do a task. The reason to break code into modules is to encourage reuse of existing code for tasks that may be done for different models, Timlin says. “If someone wanted to build a model, they would have a source to go to and say, ‘Well, here's something that's been tested. I know what it does. I can put it into my model, and I can have confidence that it will work correctly.’” Another benefit of standardizing and documenting code is to make it easier to combine models in future analyses and provide credit to code developers through a publication that can be cited. “We usually have different research groups working on different models,” David says. “One works on a plant model. One group works on a water quality model, or climate models, and all these different models need to be integrated eventually with socioeconomic models.” If models are not well documented, it is challenging and sometimes impossible to combine them, leaving researchers to write new code to perform the same task or analysis. This idea is not without some challenges. Finding appropriate reviewers and identifying long-term storage options would need to be addressed. And then there is the issue of novelty. “I think one drawback is that a lot of the code that people would publish now may not be something unique that hasn't been developed before,” Timlin says, adding that reviewers and editors would have to make decisions about what code is novel enough to be published. “I think some amount of flexibility, initially, is going to be useful.” Read the article, “Proposed Standards for Peer-Reviewed Publication of Computer Code,” in Agronomy Journal at https://doi.org/10.2134/agronj2015.0481.