Personal tools
You are here: Home / cmgui / Wiki / cmgui programming style
Log in

Forgot your password?

cmgui programming style

Code structure

  • Files in graphics directory should include files in three_d_drawing

    directory and not the other way round. The platform specific parts of implementing OpenGL (GLX, WGL, AGL) are all only in three_d_drawing.

While many of these things are just convention and open to challenge, these are the common style points

  • Captial Initial. type names generally have a their first character capitalised. Historically all types were explicitly qualified with enum or struct every time they were used. As more of the program migrates to C++ this style is being relaxed. In particular in the API "id" types are being typedefed to include the struct.

  • Line formatting. Generally everything flows on continuously. I (Shane) tend to put spaces between parameters in a function call. When a single line gets longer than about 80 characters we wrap it onto the next line and add one more level of indentation.

  • Comments. In C we generally do not use the // C++ comment. The IRIX compilers do not allow you too. For commenting out a block we tend to use #if defined (OLD_CODE) #endif /* defined (OLD_CODE) */

  • Preprocessor directives. We tend to enclose the variable in brackets and include a comment at the end to show what is being closed. I (Shane) have recently taken to indenting nested #ifs:

    #if defined (OLD_CODE)
    #  if defined (BOB)
    #  else /* defined (BOB) */
    #  endif /* defined (BOB) */
    #endif /* defined (OLD_CODE) */
  • Return codes. Most functions return either an in or a pointer. The int is normally 1 if the function was successful and 0 if not. Pointer operations (normally CREATE/constructors) can return NULL on failure. It has been a long standing discussion if we need to change our error/exception handling to allow more levels and information and to enable the calling routines to catch errors.