Basic coding style

[spir]

On Mon, 22 Nov 2010 07:29:24 -0500
bearophile <bearophileHUGS at 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