4 ms·

Meh. The longer I'm in this profession, the less I like rules like this. This is dogma that tries to do something profound but kind of encourages the reader to

by junon 4y ago

Meh. The longer I'm in this profession, the less I like rules like this. This is dogma that tries to do something profound but kind of encourages the reader to ignore past experiences. I don't agree with it, I use mixed visibility members in most languages I use. The closest "rule" to this that is more just a side effect of my experience is that most data members are private by default unless there is a public read/write contract, or if they are data members that are marked const in a language that supports such things. Beyond that, employing any sort of rule generally means you're writing more code than necessary, or less code than is helpful, and inflicting that pain on consumers or colleagues. Dogma is rarely the way to go, in my opinion. Being good at being pragmatic is certainly a skill, and it's much more powerful than a subjective rulebook.

arch-ninja 4y ago
Agreed, my experience says the same. Good compromises will win every time, and most times the communication about 2 different ways to build the same thing will end up producing a hybrid that's better than both ideas alone.
saghm 4y ago
I think the rule they present might be mostly related to the fact that they're using Rust. The combination of using structs that can be constructed from literals rather than objects (compared to Java with objects being created by constructors), having field-specific visibility on struct fields (compared to C with visibility being determined by the header file), and requiring all fields to have values specialized when constructed (compared to Go, which will implicitly initialize missing fields to the zero-value for the type) means that having mixed visibility for struct fields in Rust leaves you with the sometimes surprising behavior where you can access fields directly but run into errors when you try to create a struct by specifying all those fields. I think this rule of thumb is basically a modified version of the "use getters/setters instead of public fields" rule of thumb in Java but with an exception for fully transparent structs. It might be a bit too dogmatic to require all the time, but I think it has some merit in terms of API hygiene. If I don't want users to be able to manually construct instances of my struct, then allowing them to manually set some of the fields often might be an anti-pattern, since I presumably prevent manual construction to ensure some invariant over the fields of the struct. Enforcing this rule makes sure that you think twice about allowing arbitrary mutation over only a subset of a struct (which could lead to false assumptions about the internal state of a struct) while still giving you a fairly easy workaround if you do in fact need this (by just implementing getter/setter methods).
munificent 4y ago
A problem I often see in software engineering advice is ambiguity about how a rule is meant to be applied. I think of it like a 2D continuum. On one axis is how mechanical the rule is. One end is rules like the one in this article where even a simple automated syntactic analysis could enforce the rule. The other end is rules around high level principles that require taste and judgement to apply like the principle of least astonishment (What is "astonishment"? Whose? How is it compared?), single responsibility (What is a "responsibility"? What does it mean to uphold it?). But there is a second axis too which is how literally the guideline is meant to be applied. People often assume that the more mechanical a rule is, the more mechanical you should be in applying it, but that's not the case. It's reasonable to have simple mechanical rules that have plenty of exceptions and require some judgement to know when to ignore them. Likewise, there are vague high level principles that should almost never be violated. When someone assumes that a mechanical rule should be applied blindly, they call it "dogma", but a more charitable interpretation is that the author expects the reader to not follow the rule blindly and understand that there are reasonable exceptions. Mechanical rules can be useful, but mechanical rule-followers less so.

by junon 4y ago

arch-ninja 4y ago

Agreed, my experience says the same. Good compromises will win every time, and most times the communication about 2 different ways to build the same thing will end up producing a hybrid that's better than both ideas alone.

saghm 4y ago

I think the rule they present might be mostly related to the fact that they're using Rust. The combination of using structs that can be constructed from literals rather than objects (compared to Java with objects being created by constructors), having field-specific visibility on struct fields (compared to C with visibility being determined by the header file), and requiring all fields to have values specialized when constructed (compared to Go, which will implicitly initialize missing fields to the zero-value for the type) means that having mixed visibility for struct fields in Rust leaves you with the sometimes surprising behavior where you can access fields directly but run into errors when you try to create a struct by specifying all those fields. I think this rule of thumb is basically a modified version of the "use getters/setters instead of public fields" rule of thumb in Java but with an exception for fully transparent structs. It might be a bit too dogmatic to require all the time, but I think it has some merit in terms of API hygiene. If I don't want users to be able to manually construct instances of my struct, then allowing them to manually set some of the fields often might be an anti-pattern, since I presumably prevent manual construction to ensure some invariant over the fields of the struct. Enforcing this rule makes sure that you think twice about allowing arbitrary mutation over only a subset of a struct (which could lead to false assumptions about the internal state of a struct) while still giving you a fairly easy workaround if you do in fact need this (by just implementing getter/setter methods).

munificent 4y ago

A problem I often see in software engineering advice is ambiguity about how a rule is meant to be applied. I think of it like a 2D continuum. On one axis is how mechanical the rule is. One end is rules like the one in this article where even a simple automated syntactic analysis could enforce the rule. The other end is rules around high level principles that require taste and judgement to apply like the principle of least astonishment (What is "astonishment"? Whose? How is it compared?), single responsibility (What is a "responsibility"? What does it mean to uphold it?). But there is a second axis too which is how literally the guideline is meant to be applied. People often assume that the more mechanical a rule is, the more mechanical you should be in applying it, but that's not the case. It's reasonable to have simple mechanical rules that have plenty of exceptions and require some judgement to know when to ignore them. Likewise, there are vague high level principles that should almost never be violated. When someone assumes that a mechanical rule should be applied blindly, they call it "dogma", but a more charitable interpretation is that the author expects the reader to not follow the rule blindly and understand that there are reasonable exceptions. Mechanical rules can be useful, but mechanical rule-followers less so.