Modern C++ Best Practices

Prefer clarity over cleverness

Simple code is easier to debug, review, and extend.

Before: compact but harder to reason about

int score(const std::vector<int>& values) {
	int total = 0;
	for (auto v : values) {
		total += v > 0 ? v : 0;
	}
	return total;
}

After: intent is obvious

bool is_positive(int value) {
	return value > 0;
}

int sum_positive(const std::vector<int>& values) {
	int total = 0;
	for (int value : values) {
		if (is_positive(value)) {
			total += value;
		}
	}
	return total;
}

The second version is only slightly longer, but it exposes the rule directly and gives you a natural place for tests.

Good defaults

• Use const by default.
• Use std::vector by default for dynamic lists.
• Use std::string_view for non-owning text parameters when lifetime is safe.
• Use std::unique_ptr for exclusive ownership.
• Use algorithms over hand-written loops when intent is clearer.

These defaults reduce decision fatigue. You can deviate when you have a reason, but starting from well-understood types and idioms keeps code reviews simpler.

Design guidance

• Make illegal states hard to represent.
• Keep classes small and focused.
• Avoid hidden ownership rules.
• Minimize global state.

Example: represent valid state directly

struct ConnectionConfig {
	std::string host;
	std::uint16_t port;
};

class Client {
public:
	explicit Client(ConnectionConfig config) : config_(std::move(config)) {}

private:
	ConnectionConfig config_;
};

Prefer a validated configuration object over a class that can be default-constructed into a broken state and fixed later through multiple setter calls.

Tooling guidance

• Compile with strong warnings.
• Run sanitizers in debug builds.
• Add tests for bug fixes.
• Format automatically.

Minimum local build command

g++ -std=c++23 -Wall -Wextra -Wpedantic -g -fsanitize=address,undefined src/main.cpp -o build/app

Treat warnings and sanitizers as part of normal development, not as a cleanup phase at the end.

API design guidance

• Make ownership obvious in types and function signatures.
• Prefer returning values over output parameters.
• Use std::span and std::string_view for read-only borrowed data when lifetimes are clear.
• Mark must-check return values with [[nodiscard]].

Prefer returned values over output parameters

std::string build_label(std::string_view name, int id) {
	return std::format("{}-{}", name, id);
}

This is easier to use and test than forcing callers to allocate an output string and pass it in by non-const reference.

Use borrowed views only when lifetime is obvious

void log_names(std::span<const std::string> names);
void greet(std::string_view name);

Borrowed views are excellent API tools, but they are a bad fit when the callee needs to store the data past the call.

Error-handling guidance

• Use exceptions for exceptional failures that should unwind through multiple layers.
• Use std::optional when "no result" is normal.
• Use std::expected when callers should process structured error information.

Quick choice rule

• Use std::optional<T> when the caller only needs to know whether a value exists.
• Use std::expected<T, E> when the caller needs a useful reason for failure.
• Use exceptions when failure handling would otherwise clutter many intermediate layers.

std::expected<int, std::string> parse_port(std::string_view text) {
	int value = 0;
	auto [ptr, ec] = std::from_chars(text.data(), text.data() + text.size(), value);
	if (ec != std::errc{} || ptr != text.data() + text.size()) {
		return std::unexpected("port must be a decimal number");
	}
	return value;
}

Modern feature adoption

Adopt features that improve readability and correctness first: concepts, std::span, std::jthread, std::format, and std::expected typically pay off faster than large architecture rewrites.

Checklist for day-to-day code reviews

• Is ownership obvious from the types?
• Are names describing the business rule rather than the mechanics?
• Does the API return a value instead of mutating through an out parameter?
• Are lifetime assumptions explicit for spans, views, pointers, and references?
• Would a standard type or algorithm make the code shorter and safer?