在属性setter中添加日志语句是否符合编程最佳实践？

问题背景 #

我有一个抽象基类，其中的属性会自动将超过最大值（50）的赋值截断为50，代码如下：

public abstract class MyBaseClass
{
    private int adjustedInt;

    public int NotGreaterThanFifty
    {
        get => this.adjustedInt;
        set
        {
            this.adjustedInt = value < 50 ? value : 50;
        }
    }
}

我们需要记录所有尝试给该属性赋值超过50的情况。目前我在赋值该属性的业务类中添加了日志，覆盖了大部分场景，但仍有少数罕见场景会设置该属性。有人建议我直接在属性的Setter中添加日志，我觉得这种做法有点奇怪，想问问这是否属于良好的编程实践？

回答 #

在这个场景下，在Setter中添加日志完全是合理且符合良好编程实践的，原因如下：

• 职责内聚，规则统一：这个属性本身负责执行「值不能超过50」的截断规则，那么和该规则相关的异常触发记录，理应由属性自身来处理。毕竟属性是规则的直接执行者，所有修改该属性的操作都会经过Setter，能彻底覆盖包括罕见场景在内的所有赋值情况，不会出现遗漏。
• 避免重复冗余：如果在每个业务类里单独写日志判断，不仅会产生大量重复代码，还很容易因为新增业务场景而忘记添加日志。把日志逻辑放在Setter里，一次实现就能让所有调用方自动生效，大幅降低维护成本。
• 数据追溯更清晰：当属性值被截断时，这属于数据处理中的关键节点。在Setter里记录这个行为，能直接把「异常赋值」和「数据修改」关联起来，后续排查问题时，不用再去各个业务类的日志里翻找，直接通过属性相关的日志就能定位到数据异常的源头。

当然，实践中也有几点需要注意：

• 日志内容要精准：至少要记录原始赋值的数值、截断后的数值，如果能加上调用上下文（比如当前实例的标识、调用栈片段）会更方便定位问题。
• 不要滥用此方式：对于普通的无规则约束的属性，没必要在Setter里加日志；但对于带有业务规则、数据校验逻辑的属性，记录规则触发的情况是很有必要的。

修改后的代码示例（加入日志逻辑）：

public abstract class MyBaseClass
{
    private int adjustedInt;

    public int NotGreaterThanFifty
    {
        get => this.adjustedInt;
        set
        {
            if (value > 50)
            {
                // 替换为你实际使用的日志组件调用
                // 例如：Logger.LogWarning($"尝试为NotGreaterThanFifty赋值{value}，已自动截断为50");
                this.adjustedInt = 50;
            }
            else
            {
                this.adjustedInt = value;
            }
        }
    }
}

内容的提问来源于stack exchange，提问作者Manikanta