CS Software Paper Guidelines
Crop Science (CS) publishes papers related to computing in crop science. Papers may focus on measurement or analysis software, monitoring and control software, visualization, specialized databases and data structures, computer utilities for agronomists, comparisons of algorithms or programs, and decision support systems. Software manuscripts may be submitted as Original Research or Letters to the Editor. CS encourages authors to make their software available at no or low cost, including source code. Field applications of existing software, databases, or decision support systems typically belong in the related subject section. The editor reserves the right to reassign a paper to another section.
As with other manuscripts submitted to CS, software manuscripts must adhere to accepted scientific standards in terms of a review of relevant literature, testing, and documentation of methods. The authors must show that the software performs its stated function, which generally requires testing the methodology and presenting one or more sample applications. Because the emphasis is on the software, use of previously published data is acceptable where appropriate. Authors are encouraged to make programs and documentation available at the beginning of the review process and may be required to do so at the editor’s discretion.
Manuscripts submitted as software papers to CS should address the following issues:
What are the intended uses and users of the program?
- What does the software do? How well does it do it? Does it do it better (faster? At lower cost?) than existing methods or products?
- What need does the program address? How is the need currently being addressed, if at all?
- Is the program intended for researchers, producers, consultants and extension agents, or some other group?
- What are the limitations of the program? Are there assumptions in the program that prohibit its application to apparently related uses?
How does the program work?
- If the program uses a new algorithm, it should be described; if an established algorithm is central to it, it should be referenced. New algorithms can be described using a flowchart, pseudocode, a short segment of actual code, or a written description.
- Where helpful to the reader, longer sections of code can be provided as an appendix. Format code in a monospaced font (e.g., Letter Gothic or Courier) that clearly distinguishes between 1, l, I, O, and 0. Indent lines only where code structure requires it. If there can be any doubt about runover lines vs. new lines, add a marginal or cover note of explanation.
- If the logical flow of the entire program is of interest, it should be described via a flowchart, pseudocode, or a written description.
What is required to run the program?
- Is the program commercial, or free? If free, is it executable-only, or is the source code included? If the program is commercial, the seller, price, and user support agreements should be mentioned; if free, the copying policies, programming language, and the specific compiler or interpreter required should be specified.
- What operating systems will it run under?
- What hardware is required to run the program? Include both minimum and optimal configurations; specifying memory and graphics requirements, and any required or useful peripherals.
- How much disk space is required to store the program and associated files? How big are the required input and output files?
- Are there any supporting software requirements? For example, does the program require an interpreter or a specific spreadsheet program?
- How can the program be obtained? If possible, give both a URL for downloading (or email, for reply with file attachment) and a physical address. For the physical address, include mailing instructions.
How does the program operate from the perspective of the user?
- Is there a manual available? Is it in the form of a book, a file, or online help? Is any support available from the authors, the seller, or some other party?
- How is the program invoked and operated?
- Where truly informative, screen shots may be provided as figures. Avoid merely decorative screen shots that largely duplicate the text.
- Where sample output is useful, provide it as a table (i.e., a text file, not a graphics file). For publication, this will be formatted as a standard table, close to but not necessarily identical to the appearance of the output submitted.
- What inputs are required, and in what format? How are these inputs obtained?
- What outputs are produced, and in what format? What does the output mean?
Published on behalf of
