On 10.08.2011 21:11, bearophile wrote:
Dmitry Olshansky:
Honestly I can't get why you are so nervous about code style anyway, you
seem to bring this up way to often.
I bring it often because many D programmers seem half blind to this problem. I
am not willing to go to the extremes Go language goes to solve this problem,
but I'd like more recognition of this problem in D programmers. A bit more
common style is quite helpful to create an ecology of D programmers that share
single modules. I guess D programmers are used to C/C++ languages, where there
are not modules and where programs are usually made of many files. So they
don't see why sharing single modules in the pool is so useful.
About spaces personally I dislike eating extra vertical space for
"clarity", curly braces on it's own line is already way too much.
Think about reading a book without the half lines between paragraphs. In code
it's the same. Some empty lines are good to improve readability of the code.
Curly braces are not always present, sometimes a paragraphs ends before or
after or right on a curly brace.
Braces *are* paragraphs of code, with proper indention it's more then
enough to fell the structure. If I really need to stop in the middle
function, it's to explain something, then a single line of comment
instead of meaningless empty line (which leaves reader clueless as to
why) is good enough. Except that I'm not opposed to spaces at global scope.
Have to respectfully disagree on this, don't try to nail everything on
contracts.
Contracts don't replace unittests, they complement each other.
unittest != assert, though the former do contain asserts.
They are nice but have little value over plain assert
_unless_ we are talking about classes and _inheritance_, which isn't the
case here.
It's easy to forget to test the output of a function, the "out" contracts help
here. In structs the invariant helps you avoid forgetting to call manually a sanity test
function every time you come in and out of a method.
And there are lots of asserts here, but much more of input is
enforced since it's totally expected to supply wrong pattern (or have an
outside user to type in the pattern).
The idea is to replace those enforces with asserts, and allow user programs to
import Phobos stuff that still contain asserts (from a secondary Phobos lib).
Enforces are for certain kinds of user code, I don't think they are fit in
Phobos.
No gonna work, file I/O is certainly in Phobos, as are network sockets,
etc. You can't assert that something external won't fail. While you'd
normally assert on your local logical invariants. As for other things I
thought e.g. ranges are already hooked on asserts, as much as other
templates. If you have a list of modules where you find the lack of
compiled in contracts/asserts unbearable, do tell.
I hate being drugged in these discussions, but just can't resist.
--
Dmitry Olshansky
