Jon said:
If you buy that argument, would you suggest that everything should be
public, too?
Yes, I pretty much do. A side-benefit is much less complicated white-box
testing, since the "hiding" of implementation of state is only a hint,
not enforced.
Where possible, also outside computing, I prefer accountability to
prevention.
I admit that I occasionally declare members protected, when I know they
will change implmentation/signature within a short timeframe, or if they
are helper-functions local to the class -- since C# have no free
functions and these helpers aren't part of the behaiour of the class.
For code without security implications I believe in documenting the
risks and letting the user decide.
Prefixing with "_" can be enough documentation that this method or that
member is not for casual use, if that practice is well enough known in
the context.
I have yet to see a real example where private methods or properties do
any real good.
Locking on explicit lock objects doesn't take unlimited development
No, but it does require the programmer to do something more complicated.
Rules accumulate.
I don't particularly object to the use of an explicit lock-object. What
I don't like is stuff like:
"We strongly discourage the use of lock(this). Since other, completely
unrelated code can choose to lock on that object as well"
Which blanket states that a practice should be followed. I don't see any
other reason stated anywhere in the article.
If someone lock(x) on an object, what are they expecting?
lock(this) is preferrable in many cases, most notably those where a
data-structure internally need to lock, but callers also occasionally
need to mutually exclusively invoke multiple methods without intervention.
time, nor does it impact readability or code complexity. Indeed, it
adds flexibility, and can allows more useful locking strategies, which
I am well aware that lock(this) isn't the solution to all locking. But
it's not a bad practice that needs to be banned or workarounded either.
can detect deadlocks and offer timeouts, too:
And if those properties are needed, then by all means implement them.
I have come to prefer simplicity over almost anything, even correctness
upto a point. If it's complicated, it's probably wrong or bug-filled --
if it's simple then it may just be correct.
A very gifted co-worker and the C2 wiki:
http://c2.com/cgi/wiki have
turned me from my old habits of closing everything I didn't see a use
for to a practice where I honestly present everything along with hints
about which risks are taken by using a specific level of knowledge about
the implementation.
This link seems to be broken? i get 404.
