Le 11/03/2012 21:16, Walter Bright a écrit :
On 3/11/2012 8:34 AM, deadalnix wrote:
I do think better name isn't the problem. The problem is about
consistency, and
will persist as long as we don't agree on a guideline on that in phobos.
Changing a name just for changing it doesn't worth the cost, unless
the original
name is horribly misleading - rare case. But getting the naming
convention
consistent is of much greater importance, and justify breaking code.
Frankly, I think naming conventions are overrated. The problem is that,
as the sec vs seconds debate shows, there is not a correct answer. It
becomes a bikeshed issue. There are a lot of considerations for a name,
usually conflicting with each other. To set rules in concrete and follow
them no matter what is a formula for silly results.
I think this example is very good. The seconds/secs show us the
importance of getting consistent. Here the problem come from the fact
that some stuff has been abbreviated (msecs, usecs, . . .) and some
other hasn't (minutes, hours). Now we ends up with the tricky case of
seconds, because it is in between theses 2 worlds and 2 naming
conventions. And as we have seen, it confuses people, and have no good
solution now (either duplication of the value, which is never good,
either arbitrary choice of one naming convention).
This typically show us what problems bad naming convention occurs, and
how difficult it is solve afterward, because it breaks compatibility.
I'm not suggesting no naming convention. Naming conventions are good.
But they don't trump everything else in importance, not even close.
I have to disagree. They are really important on a large codebase (let
say > 100,000 lines of code). Otherwise people tend not to find modules
they can reuse expect by nowing the whole codebase. This have indirect
effect to cause needless duplication - with all known drawbacks - and
make the project more dependent on documentation - more documentation
have to be produced, which means an overhead in workload and more
trouble when documentation lacks, is outdated, or is bugguy.
And sometimes, a name change can be a huge win - the
invariant=>immutable one is an example. But I think that's an
exceptional case, not a rule.
IMO, the name in itself isn't that important. The important thing is
that thing get named in a predictable and simple way.
