Using the Limits Class

System.debug('Queries used: ' + Limits.getQueries() + ' / ' + Limits.getLimitQueries());
System.debug('DML used: ' + Limits.getDmlStatements() + ' / ' + Limits.getLimitDmlStatements());

Limits.getQueries() and Limits.getDmlStatements() report how many have actually run so far in the current transaction; Limits.getLimitQueries() and Limits.getLimitDmlStatements() report the actual ceiling — useful for confirming, during development, that bulkified code really is staying well within limits.

public void processInBatches(List<Account> accounts) {
    for (Account acc : accounts) {
        if (Limits.getQueries() >= Limits.getLimitQueries() - 5) {
            System.debug('Approaching query limit — stopping early.');
            break;
        }
        // ... some operation that queries related data ...
    }
}

This checks remaining query budget before each iteration that might consume more of it, stopping gracefully with a warning rather than crashing with a LimitException partway through — genuinely useful when a method's query count depends on data that can't be predicted in advance.

For well-bulkified code following this module's patterns, checking Limits methods is rarely necessary — the whole point of bulkification is staying comfortably under every limit regardless of data volume. Limits methods earn their keep specifically in complex, genuinely unpredictable scenarios (like Module 24's future recursive-trigger discussions, or processing that legitimately varies its query count based on incoming data) where confirming "how much room is actually left" adds real value.