Coding Standards

Style

We'll adhere to VTK coding standards except where noted here.

• Qt derived classes will follow Qt style for member functions. We don't want to mix two styles in one class (Qt virtual overloads & VTK style).
• Avoid multiple inheritance of Qt & VTK classes. Style in such classes would be mixed. Besides, object management is not compatible (VTK's A::New, a->Delete vs. Qt's new A(), nothing).
• Member variables will follow VTK style. In contrast, Qt headers do one of two things: use '_' prefix to prevent collisions with get methods of the same name, hide all data in an internals class/struct. Using the VTK style will lead to more readable code.

Here's an example class

/// Widget that paints a property
class pqMyWidget : public QWidget
{
  Q_OBJECT
  Q_PROPERTY(QString property READ property WRITE setProperty)
  
public:
  pqMyWidget(QWidget* parent);
  ~pqMyWidget();

  /// overloaded paint event to paint property
  virtual bool paintEvent(QPaintEvent* e);

  /// get property
  QString property() const;
  /// set property
  void setProperty(QString s);

protected:
  QString Property;
};

Comments

Historically, most VTK-style source documentation (.NAME, .SECTION, Description:, etc) has been converted into [Doxygen] compatible tags, then the source docs have been generated by Doxygen. Some projects (vtkSNL, CMake) have been using Doxygen tags directly. To capitalize on the popularity and features offered by Doxygen, all ParaQ-related source docs must use Doxygen tags. At a minimum, all public interfaces should be documented with Doxygen "brief" descriptions, but there are many useful tags available, see the [Doxygen Manual]. A couple of favorites are "\todo" and "\deprecated", which can help considerably in eliminating orphaned code.