Announcement

Collapse
No announcement yet.

VoltDB coding style guidelines

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • VoltDB coding style guidelines

    VoltDB is not as strict as some projects about coding style, but we do have a few guidelines. If you are interested in submitting code back to VoltDB, this information may be useful to you.


    Strictly enforced in the ENG repository
    1. No tabs. All indention is spaces only.
    2. No trailing whitespace.
    3. All files require an approved license comment.


    Conventions in our Java and C code
    There is a fair amount of variation, however the majority of our Java and C code base follows these conventions.


    Member fields have an "m_" prefix followed by a lower case letter and then camel case: m_updateCounter. (This isn't very Java like but is helpful in C code.) We avoid hungarian notation or other type prefix schemes.


    Java and C type names start with an uppercase letter, the common convention in those languages: public class MyDefectFreeFoo{}


    Java packages are lower case: org.voltdb.foo.bar.SomeClass


    We declare java class members at the top of the class.


    C filenames are lower case. C header files use a ".h" suffix. C source files use a ".cpp" suffix.


    Trunk should always be functional
    Code must pass all unit and integration tests (ant check) before it is committed to svn. New functionality should be committed with testcases.


    Several of us use git and git-svn locally to work with our remote svn repositories. When committing multiple changesets to svn, ensure that each individual commit produces a buildable, working state.


    Our commit hook enforcement tool is checked in at src/tools/licensecheck.py. Setting this as local git commit hook can be helpful in avoiding whitespace and license errors that the svn repository will reject.


    *--Ryan.

  • #2
    Code Page

    Thanks Ryan!


    I am only now seeing there might also be a character code page issue.

    Erlang officially uses Latin-1. UTF-8 seems to work as well. I just recently switched from UTF-8 to Latin-1 to adhere to the standard.


    What is the repository expecting? I see that e.g. ° (degree) is not displayed as ° (degree) but as ? (question mark) when I commit an ISO Latin-1 file.


    Thanks,
    Henning

    Comment


    • #3
      Subversion character encodings

      Originally posted by henning View Post
      Thanks Ryan!


      I am only now seeing there might also be a character code page issue.

      Erlang officially uses Latin-1. UTF-8 seems to work as well. I just recently switched from UTF-8 to Latin-1 to adhere to the standard.


      What is the repository expecting? I see that e.g. ° (degree) is not displayed as ° (degree) but as ? (question mark) when I commit an ISO Latin-1 file.


      Thanks,
      Henning
      Per the subversion documentation, the repository expects UTF-8 comments and filenames. Your svn client may do some character conversions behind the scenes for you. SVN treats file content as raw byte sequences.


      See http://svnbook.red-bean.com/en/1.5/svn-book.html
      Specifically: http://svnbook.red-bean.com/en/1.5/s...ed.l10n.svnuse


      *--Ryan.

      Comment

      Working...
      X