style.rst 4.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126
  1. .. _style_guidelines:
  2. Style Guidelines
  3. ================
  4. This document provides a set of guidelines to use for all GeoServer project documentation. These guidelines will help to ensure that all project documentation remains clear, consistent, and easy to read.
  5. Content conventions
  6. -------------------
  7. This section concerns the tone to use when writing text for pages.
  8. Be concise
  9. ``````````
  10. Documentation should be concise and not just a brain dump. Reference material should contain short pages and be easy to refer to without having to scroll through a large volume of text. Tutorials can be longer, depending on scope. If the point of the document is to share your thoughts and insights, it belongs in a blog post. This documentation is a manual, not a wiki.
  11. Avoid marketing
  12. ```````````````
  13. If the point of the document is to showcase a new feature it does not belong in the documentation. Write an article or a blog post about it. If it is necessary to point out a technical benefit of a feature then do so from a technical standpoint.
  14. Bad
  15. Super-overlays are a great way to publish super cool datasets awesomely in Google Earth!
  16. Good
  17. Super-overlays allow you to efficiently publish data via Google Earth.
  18. Be professional
  19. ```````````````
  20. Avoid the use of slang or other "colorful" language. The point of a technical document is to be informative, not to keep the reader amused. Avoiding slang helps keep the document accessible to as large an audience as possible.
  21. Bad
  22. Next, fire up whatever tool you use to browse the web and point it in the direction of ...
  23. Good
  24. Next, start your web browser and navigate to ...
  25. Use direct commands
  26. ```````````````````
  27. When providing step-by-step instructions, use direct commands or requests. Avoid the use of "we" and "let's".
  28. Bad
  29. Now let's add a shapefile by ...
  30. Good
  31. Add a shapefile by ...
  32. Naming conventions
  33. ------------------
  34. .. note:: Many of the guidelines in this section are taken from the `Wikipedia naming conventions <http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions>`_.
  35. Capitalization of page names
  36. ````````````````````````````
  37. Each word in the page name should be capitalized except for articles (such as "the", "a", "an") and conjunctions (such as "and", "but", "or"). A page name should never start with an article.
  38. Bad
  39. Adding a shapefile or postgis table
  40. Good
  41. Adding a Shapefile or PostGIS Table
  42. Bad
  43. The Shapefile Tutorial
  44. Good
  45. Shapefile Tutorial
  46. Capitalization of section names
  47. ```````````````````````````````
  48. Do not capitalize second and subsequent words unless the title is almost always capitalized in English (like proper names). Thus, capitalize John Wayne and Art Nouveau, but not Video Games.
  49. Bad
  50. Creating a New Datastore
  51. Good
  52. Creating a new datastore
  53. Verb usage
  54. ``````````
  55. It is recommended that the gerund (the -ing form in English) be used unless there is a more common noun form. For example, an article on swimming is better than one on swim.
  56. Bad
  57. Create a new datastore
  58. Good
  59. Creating a new datastore
  60. Avoid plurals
  61. `````````````
  62. Create page titles that are in the singular. Exceptions to this are nouns that are always plural (scissors, trousers), a small class that requires a plural (polar coordinates, Bantu languages, The Beatles).
  63. Bad
  64. Templates tutorial
  65. Good
  66. Template tutorial
  67. Formatting
  68. ----------
  69. Code and command line
  70. `````````````````````
  71. Any code or command line snippets should be formatted as code::
  72. This is a code block.
  73. When lines are longer than 77 characters, extend multiple lines in a format appropriate for the language in use. If possible, snippets should be functional when pasted directly into the appropriate target.
  74. For example, Java and XML make no distinction between a single space and multiple spaces, so the following snippets are fine::
  75. org.geoserver.package.Object someVeryLongIdentifier =
  76. org.geoserver.package.Object.factoryMethod();
  77. ::
  78. <namespace:tagname attributename="attributevalue" attribute2="attributevalue"
  79. nextattribute="this is on another line"/>
  80. For shell scripts, new lines can be escaped with a backslash character (\\). It is also recommended to use a simple ``$`` prompt to save space. For example::
  81. $ /org/jdk1.5.0*/bin/java \
  82. -cp /home/user/.m2/repository/org/geoserver/*/*.jar \
  83. org.geoserver.GeoServer -DGEOSERVER_DATA_DIR=/var/lib/geoserver_data/release