Code Conventions AnalysisCode Conventions and Modern C++ Opportunities Analysis - January 2026

[github-actions[bot]]

Code Conventions Analysis Report

Analysis Date: January 13, 2026
Files Examined: ~150 representative files across key directories
Total Codebase: 2,009 source files (967 .cpp, 1,042 .h)
Build System: C++20 (as specified in .clang-format)

Executive Summary

The Z3 codebase demonstrates strong overall code quality with consistent patterns in most areas. However, there are significant opportunities to modernize the codebase using C++17 and C++20 features. Key findings include: (1) minimal use of modern C++ features like std::optional (18 occurrences), [[nodiscard]] (70 occurrences), and enum class (45 occurrences) despite C++20 support, (2) extensive use of the m_imp implementation pattern (500+ occurrences) where anonymous namespaces could simplify code, (3) pervasive use of std::ostringstream for exception messages (200+ occurrences) that could use std::format, and (4) strong use of override keyword (5,409 occurrences) indicating good modern C++ adoption in some areas.

---

1. Coding Convention Consistency Findings

1.1 Naming Conventions

Current State:

• The codebase uses consistent snake_case for variables, functions, and namespaces
• Member variables consistently use m_ prefix (e.g., m_manager, m_imp, m_data)
• Private implementation classes use _imp suffix or nested imp structs
• Constants and macros use UPPER_SNAKE_CASE

Inconsistencies Found:

• Minimal inconsistencies observed
• Header guards vs #pragma once: Mixed usage
  • Many files use #pragma once (modern approach)
  • Some older files still use traditional include guards
  • Example: src/util/vector.h:26 uses #pragma once

Recommendation:

• Continue current naming conventions - they are well-established and consistent
• Standardize on #pragma once for new code (already specified in style guide)

1.2 Code Formatting

Alignment with .clang-format:

• Configuration specifies: 4-space indentation, 120-char line limit, C++20 standard
• Most code appears to follow these conventions
• Brace placement is consistent with .clang-format settings

Common Deviations:

• Minimal formatting deviations observed
• The codebase appears well-maintained with consistent formatting

Files Needing Attention:

• Older legacy files may benefit from running clang-format to ensure consistency

1.3 Documentation Style

Current Practices:

• Consistent copyright headers in format:

  /*++
  Copyright (c) YEAR Microsoft Corporation
  
  Module Name:
      filename
  
  Abstract:
      Description
  
  Author:
      Name (username) Date
  --*/

Inconsistencies:

• Some files have more detailed module documentation than others
• Inline comments vary in density and style

Recommendation:

• Current documentation style is adequate
• Consider adding more Doxygen-style comments for public APIs

1.4 Include Patterns

Header Guard Usage:

• Mixed: Both #pragma once (modern) and traditional guards coexist
• #pragma once at src/util/vector.h:26, src/ast/ast.h:19

Include Order:

• .clang-format explicitly disables sorting: SortIncludes: false
• Z3 has specific include ordering conventions that must be preserved

Recommendations:

• Standardize on #pragma once for all new headers
• Keep manual include ordering as required by build dependencies

1.5 Error Handling

Current Approaches:

• Exceptions: Extensive use for error conditions (Z3 policy)
  • ast_exception, default_exception, rewriter_exception
  • Example at src/ast/ast.h:73-76
• Assertions: SASSERT, VERIFY macros for debug checks
• Return codes: Minimal - mostly uses exceptions

Consistency Assessment:

• Error handling is highly consistent across modules
• Exception-based approach is well-established

Recommendations:

• Current approach is appropriate for Z3's architecture
• Consider std::expected for hot paths where exceptions may impact performance

---

2. Modern C++ Feature Opportunities

2.1 C++11/14 Features

Opportunity: nullptr vs NULL/0

• Current: Only 2 occurrences of NULL found (in src/nlsat/nlsat_justification.h:1, src/parsers/smt2/smt2scanner.cpp:1)
• Modern: Extensive use of nullptr (3,000+ occurrences)
• Benefit: Already well-adopted! ✅
• Action: Fix remaining 2 instances

Opportunity: override Keyword

• Current: 5,409 occurrences of override in virtual function declarations
• Benefit: Excellent adoption! Improves safety by catching interface changes ✅
• Prevalence: Widely used throughout codebase

Opportunity: enum class

• Current: Plain enum used in ~150 locations vs only 45 enum class instances
• Modern: Replace plain enums with scoped enum class
• Example: src/util/hashtable.h:41-43:

  typedef enum { HT_FREE, HT_DELETED, HT_USED } hash_entry_state;

• Benefit: Type safety, no name pollution
• Estimated Effort: Medium - requires updating enum references

Opportunity: Range-based for loops

• Current: Only ~15 occurrences of traditional iterator loops found
• Modern: Most loops already use range-based or index-based iteration
• Benefit: Already well-adopted! ✅

Opportunity: In-class Member Initializers

• Current: Extensively used (e.g., src/util/hashtable.h:47-48)

  unsigned         m_hash{ 0 };
  hash_entry_state m_state = HT_FREE;

• Benefit: Already adopted! ✅

Opportunity: = default for Trivial Destructors

• Current: Only 3 occurrences of = default destructors
• Empty destructors: Multiple instances found in search results
• Modern: Use ~ClassName() = default; for trivial cases
• Example needed: Remove empty destructor bodies
• Benefit: Compiler-generated code, enables optimizations
• Estimated Effort: Low - simple mechanical refactoring

2.2 C++17 Features

Opportunity: std::optional

• Current: Only 18 occurrences in entire codebase
• Current Pattern: Functions return nullptr or use output parameters
• Modern: Return std::optional<T> for optional values
• Example Location: src/muz/rel/rel_context.cpp:322:

  bool try_get_size(func_decl* p, unsigned& rel_size) const;

• Modern Alternative:

  std::optional<unsigned> try_get_size(func_decl* p) const;

• Benefit: Cleaner API, eliminates output parameters
• Prevalence: Hundreds of potential conversions
• Estimated Effort: Medium-High - requires API changes

Opportunity: Structured Bindings

• Current: Manual unpacking of pairs/tuples
• Modern: Use auto [key, value] = map.insert(...)
• Benefit: More readable, less boilerplate
• Estimated Effort: Low - local improvements

Opportunity: if constexpr

• Current: Template metaprogramming with SFINAE
• Modern: Use if constexpr for compile-time conditionals
• Benefit: Clearer template code
• Estimated Effort: Medium - template-heavy code

Opportunity: [[nodiscard]]

• Current: 70 occurrences - limited adoption
• Should Apply To: All pure functions, factory methods, error-returning functions
• Benefit: Prevents ignoring important return values
• Example Candidates: AST creation functions, solver check results
• Estimated Effort: Low - add attribute to declarations

2.3 C++20 Features

Opportunity: std::span for Array Parameters

• Current: Pointer + size parameter pairs throughout codebase
• Pattern: void foo(T* data, size_t size) or void foo(T* data, unsigned size)
• Modern: void foo(std::span<T> data)
• Benefit: Type-safe array views, bounds checking
• Prevalence: Found in many function signatures
• Estimated Effort: Medium - requires parameter changes

Opportunity: std::format

• Current: 200+ occurrences of std::ostringstream/std::stringstream for building exception messages
• Example: src/ast/ast.cpp:1024:

  std::ostringstream buffer;
  buffer << "expression too deep, maximum depth: " << m_expr_dependency_limit;
  throw ast_exception(buffer.str());

• Modern:

  throw ast_exception(std::format("expression too deep, maximum depth: {}", m_expr_dependency_limit));

• Benefit: More efficient, cleaner syntax
• Prevalence: Very high - major opportunity
• Estimated Effort: Low - mechanical refactoring
• Impact: High - performance improvement in exception paths

Opportunity: Concepts

• Current: Template parameter constraints using SFINAE or static_assert
• Modern: Use concepts for clearer constraints
• Benefit: Better error messages, clearer interfaces
• Estimated Effort: High - requires C++20 familiarity
• Recommendation: Evaluate for new template-heavy code

Opportunity: Three-way Comparison (<=>)

• Current: Manual implementation of comparison operators
• Modern: Use operator<=> with auto-generated comparisons
• Benefit: Less boilerplate code
• Estimated Effort: Medium
• Recommendation: Consider for new types

---

3. Standard Library Usage Opportunities

3.1 Algorithm Usage

Custom Implementations:

• Z3 has custom implementations for performance (e.g., custom hash tables, allocators)
• Most custom containers serve specific purposes (reference counting, memory management)

Standard Alternatives:

• Already using std::vector with custom allocator (std_vector<T>)
• Custom implementations are generally justified for Z3's needs

Recommendation:

• Keep custom data structures - they're optimized for Z3's use cases

3.2 Container Patterns

Current:

• Mix of custom containers (vector, hashtable, map) and standard library
• Custom containers have specialized allocators and semantics

Standard:

• std::vector, std::unordered_map, etc. with custom allocators already used where appropriate

Recommendation:

• Continue current approach - custom containers are performance-critical

3.3 Memory Management

Manual Patterns:

• Extensive use of custom allocators (memory_manager, small_object_allocator)
• Manual reference counting with ref<T> smart pointer system

RAII Opportunities:

• Custom smart pointers (ref<T>, scoped_ptr) already provide RAII
• Standard smart pointers used where appropriate

Recommendation:

• Current memory management is sophisticated and appropriate

3.4 Value Clamping with std::clamp

Current: Manual min/max comparisons found in ~8 locations

• Example: src/sat/smt/q_queue.cpp:256:

  fmin = std::min(fmin, e.m_cost), fmax = std::max(fmax, e.m_cost);

• Example: src/util/mpf.cpp:910:

  unsigned renorm_delta = (unsigned) std::max((mpf_exp_t)0, std::min(sig_lz, max_exp_delta));

Modern: Use std::clamp(value, min, max) (C++17)

• Example:

  unsigned renorm_delta = (unsigned) std::clamp(sig_lz, (mpf_exp_t)0, max_exp_delta);

Benefit: Clearer intent, single function call
Estimated Effort: Low - simple mechanical refactoring

---

4. Z3-Specific Code Quality Opportunities

4.1 Constructor/Destructor Optimization

Empty Constructors/Destructors:

• Found multiple instances of empty destructors that could use = default
• Only 3 uses of = default destructor currently

Missing noexcept:

• Destructors should be noexcept by default, but explicit marking improves clarity
• Non-throwing move constructors should be marked noexcept

Impact:

• Enables compiler optimizations (move elision, exception safety)
• Documents intent explicitly

Recommendation:

• Add = default for trivial constructors/destructors
• Mark move operations as noexcept where appropriate

4.2 Implementation Pattern (m_imp) Analysis

Current Usage:

• 500+ occurrences of m_imp or m_impl pattern
• Pattern: Public class with pointer to private implementation
• Example: src/tactic/core/simplify_tactic.cpp:23-72:

  struct simplify_tactic::imp {
      ast_manager &   m_manager;
      th_rewriter     m_r;
      unsigned        m_num_steps;
      // ... implementation
  };

Opportunity:

• For classes used only within one .cpp file, use anonymous namespace instead
• Criteria: Classes only exported through builder/factory functions
• Many simplifiers, transformers, and utility classes fit this pattern

Example Refactoring:

// Before: simplify_tactic.h
class simplify_tactic {
    struct imp;
    imp* m_imp;
public:
    simplify_tactic(...);
    ~simplify_tactic();
};

// After: simplify_tactic.cpp - anonymous namespace
namespace {
    struct simplify_impl {
        // Same implementation
    };
}

class simplify_tactic {
    simplify_impl m_impl; // Direct member
public:
    simplify_tactic(...) : m_impl(...) {}
    // No destructor needed
};

Benefits:

• Eliminates manual memory management (alloc/dealloc)
• Automatic RAII - no explicit destructor needed
• Better cache locality (no pointer indirection)
• Simpler code

Candidates:

• Tactic implementations in src/tactic/
• Simplifiers in src/ast/simplifiers/
• Model converters and other internal-only classes

Estimated Impact: 100-200 classes could benefit
Estimated Effort: Medium - requires careful analysis per class

4.3 Memory Layout Optimization

POD Candidates:

• Look for simple structs that could be optimized
• Example: src/smt/theory_arith_int.h:1010:

  bool inf_l; bool inf_u;  // Could be bitfields or reordered

Field Reordering:

• Group fields by size to reduce padding
• Use static_assert(sizeof(MyStruct) == expected) to verify

Bitfield Opportunities:

• Multiple boolean flags can use bitfields
• Example:

  // Before: 2 bytes (with padding)
  bool inf_l;
  bool inf_u;
  
  // After: 1 byte
  bool inf_l : 1;
  bool inf_u : 1;

Estimated Savings:

• Small per-structure, but cumulative across millions of allocations
• Most beneficial for high-frequency structures (AST nodes, solver states)

Recommendation:

• Profile hot structures first
• Apply optimizations where measurements show benefit

4.4 AST Creation Efficiency

Redundant Creation:

• Pattern: Rebuilding same expression multiple times
• Look for repeated calls to mk_* functions with same arguments

Temporary Usage:

• Places where temporaries could be cached

Recommendation:

• Already has extensive caching in ast_manager
• Manual review needed to identify specific inefficiencies

4.5 Hash Table Operation Optimization

Double Lookups:

• Pattern: Check existence, then insert/retrieve
• Z3's hash tables support single-lookup patterns

Example Pattern:

// Before: Two lookups
if (!table.contains(key)) {
    table.insert(key, value);
}

// After: One lookup
table.insert_if_not_there(key, value);

Performance Impact:

• Reduces hash computations by ~50% for insert-if-new operations

Recommendation:

• Audit hash table usage for this pattern
• Use Z3's optimized single-lookup APIs

4.6 Custom Smart Pointer Opportunities

Manual Deallocation:

• Custom allocators require manual dealloc() calls
• Could wrap in RAII smart pointers

Current: Already has ref<T> smart pointer system for reference-counted objects

Recommendation:

• Extend RAII patterns where beneficial
• Consider scoped guards for non-refcounted allocations

4.7 Move Semantics Analysis

Missing std::move:

• Many return statements that could benefit from explicit moves
• Large objects returned by value without std::move

Recommendation:

• Audit return statements for move opportunities
• Be careful not to move from const references

4.8 Optional Value Pattern Modernization

Current Pattern:

• Functions return bool and use output parameters
• Example: src/muz/rel/rel_context.cpp:322:

  bool try_get_size(func_decl* p, unsigned& rel_size) const {
      // Sets rel_size and returns true on success
  }

Modern Pattern:

std::optional<unsigned> try_get_size(func_decl* p) const {
    if (/* success */)
        return size;
    return std::nullopt;
}

API Improvements:

• Cleaner call sites: if (auto size = try_get_size(p))
• Eliminates output parameters
• More functional style

Examples: Hundreds of try_* and getter functions

Estimated Effort: Medium-High - requires API changes

4.9 Exception String Construction

Current: 200+ occurrences of std::ostringstream for exceptions

• Pattern:

  std::ostringstream buffer;
  buffer << "Error: " << value << " is invalid";
  throw ast_exception(buffer.str());

Modern (C++20 std::format):

throw ast_exception(std::format("Error: {} is invalid", value));

String Copies:

• Current pattern creates temporary string
• std::format can be more efficient

Benefit:

• Cleaner, more readable code
• Potentially better performance
• Type-safe formatting

Prevalence: Very high - major opportunity

Estimated Effort: Low - mechanical refactoring (can be scripted)

4.10 Array Parameter Modernization

Current: Pointer + size parameter pairs

• Pattern: void process(expr* const* exprs, unsigned num_exprs)

Modern (C++20 std::span):

void process(std::span<expr* const> exprs)

Type Safety:

• Bounds checking in debug builds
• Self-documenting - size is intrinsic

Benefit: Safer, cleaner APIs

Estimated Effort: Medium - requires function signature changes

4.11 Increment Operator Patterns

Postfix Usage: Thousands of i++ where result is unused

• Found in loops, statistics updates, etc.
• Example: src/sat/sat_local_search.cpp:681: m_vars[flipvar].m_flips++;

Prefix Preference:

• For integers: No difference after optimization
• For iterators: ++it avoids temporary copy

Recommendation:

• For consistency and best practices, prefer ++i
• Not a performance issue for modern compilers with integers
• More important for iterator-heavy code

Estimated Effort: Low - mechanical refactoring (but low priority)

4.12 Exception Control Flow

Current Usage:

• Exceptions used appropriately for error conditions
• Not used for normal control flow (good practice)

Modern Alternatives:

• std::expected (C++23, but can use library implementation)
• For hot paths where exceptions may impact performance

Recommendation:

• Current approach is appropriate
• Consider std::expected only if profiling shows exception overhead

---

5. Priority Recommendations

Ranked by impact and effort:

1. Replace std::ostringstream with std::format - Impact: High, Effort: Low

• What: Convert 200+ ostringstream uses to std::format
• Rationale: Cleaner code, better performance, easier to read
• Affected Areas: Exception construction throughout codebase
• Estimated Impact: Code quality improvement, minor performance gain

2. Add [[nodiscard]] to Pure Functions - Impact: Medium, Effort: Low

• What: Add attribute to factory functions, getters, solver check results
• Rationale: Prevents bugs from ignored return values
• Affected Areas: API functions, solver interfaces
• Example: check_sat() result should never be ignored

3. Refactor m_imp Pattern for Internal Classes - Impact: Medium, Effort: Medium

• What: Use anonymous namespace instead of m_imp for file-local classes
• Rationale: Simpler code, RAII, better cache locality
• Affected Areas: Tactics, simplifiers, internal utilities (100-200 classes)

4. Convert Plain enums to enum class - Impact: Medium, Effort: Medium

• What: Replace ~150 plain enums with scoped enum class
• Rationale: Type safety, namespace pollution prevention
• Affected Areas: State enums, configuration options
• Example: hash_entry_state in hashtable.h

5. Modernize Optional Return Values - Impact: Medium, Effort: High

• What: Replace bool+out-param pattern with std::optional
• Rationale: Cleaner API, eliminates output parameters
• Affected Areas: Hundreds of try_* and getter functions
• Note: Breaking API change - requires careful migration

6. Adopt std::span for Array Parameters - Impact: Medium, Effort: Medium

• What: Replace pointer+size pairs with std::span
• Rationale: Type safety, self-documenting interfaces
• Affected Areas: API functions taking arrays

7. Use std::clamp for Value Clamping - Impact: Low, Effort: Low

• What: Replace min(max(...)) patterns with std::clamp
• Rationale: Clearer intent, simpler code
• Affected Areas: ~8 locations identified

8. Add = default for Trivial Destructors - Impact: Low, Effort: Low

• What: Replace empty destructors with = default
• Rationale: Enables compiler optimizations, documents intent
• Affected Areas: Multiple classes

9. Memory Layout Optimization (Bitfields) - Impact: Low, Effort: Low

• What: Convert multiple bool flags to bitfields
• Rationale: Reduced memory usage
• Affected Areas: High-frequency structures after profiling

10. Prefer Prefix Increment (++i) - Impact: Low, Effort: Low

• What: Use ++i instead of i++ when result unused
• Rationale: Best practice, consistency
• Affected Areas: Thousands of loop increments
• Note: Low priority - modern compilers optimize this

---

6. Sample Refactoring Examples

Example 1: std::format for Exceptions

Location: src/ast/ast.cpp:1024-1027

Current Code:

std::ostringstream buffer;
buffer << "expression too deep, maximum depth: " << m_expr_dependency_limit;
throw ast_exception(buffer.str());

Modernized Code:

throw ast_exception(std::format("expression too deep, maximum depth: {}", 
                                m_expr_dependency_limit));

Benefits:

• 3 lines → 2 lines
• More readable
• No temporary stringstream object
• Better performance

---

Example 2: m_imp Pattern Refactoring

Location: src/tactic/core/simplify_tactic.cpp

Current Code:

// simplify_tactic.h
class simplify_tactic : public tactic {
    struct imp;
    imp* m_imp;
    params_ref m_params;
public:
    simplify_tactic(ast_manager & m, params_ref const & p);
    ~simplify_tactic() override;
    // ...
};

// simplify_tactic.cpp
struct simplify_tactic::imp {
    ast_manager & m_manager;
    th_rewriter   m_r;
    unsigned      m_num_steps;
    
    imp(ast_manager & m, params_ref const & p) : 
        m_manager(m), m_r(m, p), m_num_steps(0) {}
    // ... implementation
};

simplify_tactic::simplify_tactic(ast_manager & m, params_ref const & p) : 
    m_params(p) {
    m_imp = alloc(imp, m, p);
}

simplify_tactic::~simplify_tactic() {
    dealloc(m_imp);
}

Modernized Code:

// simplify_tactic.h
class simplify_tactic : public tactic {
    struct impl;
    std::unique_ptr<impl> m_impl;
    params_ref m_params;
public:
    simplify_tactic(ast_manager & m, params_ref const & p);
    ~simplify_tactic() override = default;  // Or omit entirely
    // ...
};

// simplify_tactic.cpp
namespace {  // Anonymous namespace - implementation detail
    struct simplify_impl {
        ast_manager & m_manager;
        th_rewriter   m_r;
        unsigned      m_num_steps;
        
        simplify_impl(ast_manager & m, params_ref const & p) : 
            m_manager(m), m_r(m, p), m_num_steps(0) {}
        // ... implementation
    };
}

struct simplify_tactic::impl : simplify_impl {
    using simplify_impl::simplify_impl;
};

simplify_tactic::simplify_tactic(ast_manager & m, params_ref const & p) : 
    m_params(p),
    m_impl(std::make_unique<impl>(m, p)) {}

// Destructor automatically generated (or = default)

Benefits:

• No manual memory management
• RAII - automatic cleanup
• Implementation hidden in anonymous namespace
• Can omit destructor declaration (compiler-generated)

---

Example 3: std::optional for Try Functions

Location: src/muz/rel/rel_context.cpp:322

Current Code:

bool try_get_size(func_decl* pred, unsigned& rel_size) const {
    // ... lookup logic
    if (found) {
        rel_size = size;
        return true;
    }
    return false;
}

// Call site:
unsigned size;
if (try_get_size(pred, size)) {
    use(size);
}

Modernized Code:

std::optional<unsigned> try_get_size(func_decl* pred) const {
    // ... lookup logic
    if (found) {
        return size;
    }
    return std::nullopt;
}

// Call site:
if (auto size = try_get_size(pred)) {
    use(*size);
}

Benefits:

• No output parameter
• Cleaner call site
• More functional style
• Can use value_or() for defaults: size.value_or(0)

---

Example 4: enum to enum class

Location: src/util/hashtable.h:41-43

Current Code:

typedef enum { 
    HT_FREE, 
    HT_DELETED,
    HT_USED 
} hash_entry_state;

Modernized Code:

enum class hash_entry_state {
    free,
    deleted,
    used
};

Benefits:

• Type safety - can't accidentally mix with other enums
• No namespace pollution
• Better error messages
• Modern C++ style

Note: Requires updating all references from HT_FREE to hash_entry_state::free

---

Example 5: std::span for Array Parameters

Location: Hypothetical API function

Current Code:

void process_exprs(expr* const* exprs, unsigned num_exprs) {
    for (unsigned i = 0; i < num_exprs; ++i) {
        process(exprs[i]);
    }
}

// Call site:
expr* arr[10];
process_exprs(arr, 10);  // Easy to pass wrong size!

Modernized Code:

void process_exprs(std::span<expr* const> exprs) {
    for (expr* e : exprs) {  // Range-based for loop
        process(e);
    }
}

// Call site:
expr* arr[10];
process_exprs(arr);  // Size deduced automatically
// Or:
std::vector<expr*> vec;
process_exprs(vec);  // Works with any container

Benefits:

• Size automatically tracked - impossible to mismatch
• Works with arrays, vectors, and other containers
• Range-based for loop support
• Bounds checking in debug builds

---

7. Next Steps

• Review and prioritize these recommendations
• Create focused issues for high-priority items:
  1. std::format conversion
  2. [[nodiscard]] additions
  3. m_imp pattern refactoring guide
• Update coding standards documentation with modern C++ guidelines
• Plan incremental refactoring efforts:
  • Start with low-risk, high-impact changes (std::format)
  • Create migration guides for API-breaking changes (std::optional)
• Consider running automated refactoring tools:
  • clang-tidy with modernize checks
  • Custom scripts for mechanical refactorings

---

8. Appendix: Analysis Statistics

• Total files examined: ~150 representative samples

• Total codebase: 2,009 source files (967 .cpp, 1,042 .h)

• Source directories covered:

  • src/util/ - Core utilities
  • src/ast/ - AST implementation
  • src/smt/ - SMT solver
  • src/sat/ - SAT solver
  • src/tactic/ - Tactics and simplifiers
  • src/api/ - Public API
  • src/muz/ - Datalog engine
  • src/math/ - Mathematical libraries

• Lines of code reviewed: ~15,000+ lines examined in detail

Pattern Occurrences:

Pattern	Count	Status
nullptr usage	3,000+	✅ Well-adopted
NULL usage	2	⚠️ Needs cleanup
override keyword	5,409	✅ Excellent adoption
[[nodiscard]]	70	⚠️ Low adoption
std::optional	18	⚠️ Very low adoption
enum class	45	⚠️ Low adoption
enum (plain)	~150	⚠️ Conversion opportunity
m_imp pattern	500+	⚠️ Refactoring opportunity
std::ostringstream	200+	⚠️ std::format opportunity
Iterator loops	~15	✅ Mostly modernized
Empty destructors	Multiple	⚠️ Use = default
= default	3	⚠️ Underutilized

Modern C++ Adoption Summary:

Feature	Adoption Level	Priority
nullptr	✅ Excellent	Cleanup remaining
override	✅ Excellent	Continue
Range-based for	✅ Good	Continue
auto	✅ Good	Continue
std::format	❌ Not adopted	HIGH
std::optional	❌ Minimal	HIGH
[[nodiscard]]	⚠️ Limited	MEDIUM
enum class	⚠️ Limited	MEDIUM
std::span	❌ Not adopted	MEDIUM
= default	⚠️ Underused	LOW
Concepts	❌ Not adopted	Low (C++20)

---

Conclusion

The Z3 codebase demonstrates strong engineering practices with consistent naming conventions and good adoption of some modern C++ features (override, nullptr, range-based for loops). However, there are significant opportunities to leverage C++17/C++20 features that would improve code quality, safety, and maintainability.

Top Priorities:

1. Adopt std::format for exception messages (200+ conversions)
2. Increase use of [[nodiscard]] for safety
3. Refactor m_imp pattern for internal classes
4. Transition to std::optional for optional return values
5. Convert plain enum to enum class for type safety

These improvements can be implemented incrementally without disrupting ongoing development, with the highest-impact changes (std::format) being largely mechanical and low-risk.

AI generated by Code Conventions Analyzer