On Mon, 22 Nov 2010 07:29:24 -0500
bearophile <bearophileh...@lycos.com> wrote:
> From what I'm seeing in D.learn there is a problem in the D community: some
> people seem irrationally attached to the idea they are free to write D code
> as they like. I have four or five times tried to explain why coding standards
> are important for the development of the D community, but it seems not
> everybody is understanding it.
>
> So I suggest everyone that understands this problem to assume a more rigid
> and strict attitude toward this problem, because the D2 language community is
> just starting to develop now, and you don't want it to become the mess the
> C/C++ world it. I am talking about cases of struct/class names, cases of
> function names, and few other things.
>
> If I import a module written by another person, I don't want to look in the
> docs every time to know if the names start with upper case or lower case, and
> I don't want a module of mine that uses three modules written by other people
> to look like a patchwork of different styles (because half of it uses an API
> with a style and half of it with another API and some bits written in a third
> way).
>
> If you don't act now, adopting less tolerance, this will lead to a mess.
>
> Bye,
> bearophile
I heartfully agree with the big picture. A shared culture is very important in
a programming community. But it's hard to achieve, probably impossible. Three
notes.
Having a sensible and consistent naming norm would first require updating the
language's own builtin names, mainly C legacy. Below a short set of _examples_
(I don't mean at all these names are good -- just an example):
uint, int, float, bool, char, string, true, false, null
Natural, Int(eger), Real, Logical, Char(acter), Text, TRUE, FALSE, NULL
Whitespace, an important part of code aspect, can hardly be normalised. For
instance, it seems that many D coders follow this bracing scheme:
void func(string[] strings)
{
string[] result;
foreach (auto s ; strings)
{
if (s != "")
{
writefln("found: %s", s);
result ~= s;
}
}
}
My preferred style would be:
void func(string[] strings) {
string[] result;
foreach (auto s ; strings) {
if (s != "") {
writefln("found: %s", s);
result ~= s; }}}
maybe because I have coded in Lisp for some time, mainly because I do not like
losing 2 lines of valuable vertical space per block. Indentation is for me what
marks a block, braces are just noise required by the parser. In an attempt for
a compromise, I use in fact:
void func(string[] strings) {
string[] result;
foreach (auto s ; strings) {
if (s != "") {
writefln("found: %s", s);
result ~= s;
}
}
}
which saves one line per block. But I'm not happy with it. Such considerations
are very personal. There is about 0.0% chance to convince anyone else (don't
try to convince me, it time lost ;-).
Finally, for any reason I cannot guess, D docs are placed _before_ what they
comment instead of _inside_ (except for modules, indeed). You will never make
me do that: this way eats half of vertical space with doc comments. I want docs
of elements (funcs, structs, classes) irrelevant to what I'm presently dealing
with to be folded with the code. Only relevant elements remain visible,
unfolded. Docs should appear only for presently relevant elements. That's my
way, fitting my view and coding practice; you won't make me change on that ;-)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
