Thank you for your interest in contributing to QuickFIX! This document provides guidelines and information for contributors.

• Code of Conduct
• How to Contribute
• Reporting Bugs
• Suggesting Features
• Pull Requests
• Coding Standards
• Testing
• Documentation

This project adheres to a Code of Conduct. By participating, you are expected to uphold this code.

Before creating a bug report:

1. Check the existing issues to avoid duplicates
2. Collect relevant information about your environment

When creating a bug report, include:

• Title: Clear and descriptive title
• Description: Detailed description of the issue
• Steps to Reproduce: Step-by-step instructions
• Expected Behavior: What you expected to happen
• Actual Behavior: What actually happened
• Environment:
  • QuickFIX version
  • Operating system and version
  • Compiler and version
  • FIX version being used
  • Any relevant configuration
• Code Sample: Minimal code to reproduce the issue
• Logs: Relevant log output (use code blocks)

Feature requests are welcome! When suggesting a feature:

1. Check existing issues and discussions first
2. Provide a clear use case
3. Explain why this feature would benefit QuickFIX users
4. Consider backward compatibility

We actively welcome pull requests!

1. Fork and Clone: Fork the repository and clone your fork

   git clone https://github.com/YOUR-USERNAME/quickfix.git
   cd quickfix
   git remote add upstream https://github.com/quickfix/quickfix.git

2. Create a Branch: Create a feature branch from master

   git checkout -b feature/your-feature-name

3. Make Changes: Implement your changes following our coding standards

4. Test: Ensure all tests pass

   # CMake
   cmake --build . --target test
   
   # Autotools
   make check

5. Commit: Write clear, concise commit messages

   git commit -m "Add feature: brief description"

6. Push: Push to your fork

   git push origin feature/your-feature-name

7. Open a PR: Create a pull request from your fork to quickfix/quickfix:master

• Title: Clear, descriptive title
• Description:
  • What changes were made
  • Why the changes were necessary
  • Reference any related issues (e.g., "Fixes #123")
• Scope: Keep PRs focused on a single feature or bug fix
• Tests: Include tests for new functionality
• Documentation: Update documentation for API changes
• Format: Ensure code is properly formatted (run clang-format)
• Backward Compatibility: Avoid breaking changes when possible

QuickFIX uses .clang-format for code formatting. Format your code before submitting:

# Format all modified files
git diff --name-only | grep -E '\.(cpp|h)$' | xargs clang-format -i

• C++ Standard: Minimum C++17
• Naming Conventions:
  • Classes: PascalCase (e.g., SocketInitiator)
  • Functions/Methods: camelCase (e.g., sendMessage())
  • Member variables: m_camelCase (e.g., m_sessionID)
  • Constants: UPPER_CASE (e.g., MAX_BUFFER_SIZE)
• Headers: Use #pragma once for header guards
• Includes: Order includes as:
  1. Corresponding header (for .cpp files)
  2. C++ standard library
  3. Third-party libraries
  4. QuickFIX headers
• Comments:
  • Use Doxygen-style comments for public APIs
  • Explain "why" not "what" in implementation comments
• Error Handling: Use exceptions appropriately
• Memory Management: Use RAII, smart pointers when appropriate

#pragma once

#include <memory>
#include <string>

namespace FIX
{

/// @brief Represents a FIX session
class Session
{
public:
    /// @brief Constructor
    /// @param sessionID The session identifier
    explicit Session(const SessionID& sessionID);

    /// @brief Send a message
    /// @param message The message to send
    /// @return true if sent successfully
    bool sendMessage(const Message& message);

private:
    SessionID m_sessionID;
    std::unique_ptr<MessageStore> m_store;
};

} // namespace FIX

# CMake
cmake --build . --target test

# Autotools
make check

# Run specific tests
./test/ut --quickfix-config-file cfg/ut.cfg

• Add unit tests for new functionality in the test/ directory
• Use the Catch2 test framework
• Test edge cases and error conditions
• Ensure tests are deterministic and don't depend on external state

We aim for high test coverage. When adding new features:

• Write tests that cover the main functionality
• Test error paths
• Test boundary conditions

• Use Doxygen comments for public APIs
• Keep comments up-to-date with code changes
• Document parameters, return values, and exceptions

When making user-facing changes:

• Update relevant HTML documentation in doc/html/
• Update README.md if needed
• Update configuration.html for new settings
• Provide examples when appropriate

cd doc
./document.sh  # Unix/Linux
# or
document.bat   # Windows

1. Install Prerequisites:

   • C++17 compiler
   • CMake 3.5+
   • Optional: OpenSSL, MySQL, PostgreSQL

2. Build in Development Mode:

   cmake -DCMAKE_BUILD_TYPE=Debug -DQUICKFIX_TESTS=ON .
   make -j$(nproc)

3. Enable clang-format integration in your IDE/editor

• Build with -DCMAKE_BUILD_TYPE=Debug
• Use standard C++ debugging tools (gdb, lldb, Visual Studio debugger)
• Check logs in the FileStore directory

• Use Visual Studio 2019 or later
• For SSL support, install OpenSSL and set OPENSSL_ROOT_DIR
• Tests can be run from Visual Studio or command line

• Install development packages: build-essential cmake
• For SSL: libssl-dev
• For MySQL: libmysqlclient-dev
• For PostgreSQL: libpq-dev

• Install Xcode Command Line Tools
• Use Homebrew for dependencies: brew install openssl cmake

• Questions: Use GitHub Discussions
• Chat: Join the community on the mailing list
• Issues: For bugs and feature requests only

Contributors will be recognized in the project's contributor list. Significant contributions may be highlighted in release notes.

Thank you for contributing to QuickFIX!