I'm translating the library Botan and I'm at a point where I have to ask myself if I'm going to change functions and object names respectively from snake_case and Camel_Case to camelCase and CamelCase. Same goes for file names. Is this a strict rule for D libraries?

Etienne:

> I'm translating the library Botan and I'm at a point where I have to ask myself if I'm going to change functions and object names respectively from snake_case and Camel_Case to camelCase and CamelCase. Same goes for file names. Is this a strict rule for D libraries?

Take a look:
http://dlang.org/dstyle.html

Bye,
bearophile

Personally, I don't really care about naming conventions. I prefer the camelCase and it seems most D people do, but if you're translating another library, there's value it keeping it the same for ease of documentation lookups from the original etc.

On 2014-11-10 11:16 AM, Adam D. Ruppe wrote:
> Personally, I don't really care about naming conventions. I prefer the
> camelCase and it seems most D people do, but if you're translating
> another library, there's value it keeping it the same for ease of
> documentation lookups from the original etc.

I was thinking the same but sure am glad to hear you say it :D

On Mon, 10 Nov 2014 16:16:04 +0000
"Adam D. Ruppe via Digitalmars-d-learn"
<digitalmars-d-learn@puremagic.com> wrote:

> Personally, I don't really care about naming conventions. I prefer the camelCase and it seems most D people do, but if you're translating another library, there's value it keeping it the same for ease of documentation lookups from the original etc.
+1 to this. it's better to use camelCase for shiny new code, but for ports it's desirable to keep names unchanged where appropriate, for easy googling and so.

On Mon, Nov 10, 2014 at 09:19:58PM +0200, ketmar via Digitalmars-d-learn wrote:
> On Mon, 10 Nov 2014 16:16:04 +0000
> "Adam D. Ruppe via Digitalmars-d-learn"
> <digitalmars-d-learn@puremagic.com> wrote:
> 
> > Personally, I don't really care about naming conventions. I prefer the camelCase and it seems most D people do, but if you're translating another library, there's value it keeping it the same for ease of documentation lookups from the original etc.
> +1 to this. it's better to use camelCase for shiny new code, but for ports it's desirable to keep names unchanged where appropriate, for easy googling and so.

I have to say that I *hate* camelCase... it looks really ugly. But what looks uglier is a mixture of camelCase and something else. And since Phobos is all camelCased, and almost all D code uses Phobos, writing your own code with something else makes it doubly ugly. So nowadays I just use Phobos style for my own code. :-P  Nevertheless, I still dislike camelCase.

But as in any group project, especially large ones, the best policy is to follow the coding style of the surrounding code, even if it clashes with your own. Even worse than mixing camelCase with non_camel_case, is a source file that looks like a mosaic (or complete jumble) of multiple, incompatible coding styles all thrown together. An unfortunately frequent occurrence in large group projects without an adopted set of coding conventions. :-(


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!

Hard styling rules only apply to Phobos contributions. Any other project can have their own, for example, vibe.d requires own style which is incompatible with Phobos.

For ported 3d party library value of minimizing the diff is indeed more important than styling.

On Mon, 10 Nov 2014 11:35:04 -0800
"H. S. Teoh via Digitalmars-d-learn"
<digitalmars-d-learn@puremagic.com> wrote:

> I have to say that I *hate* camelCase... it looks really ugly. But what looks uglier is a mixture of camelCase and something else. And since Phobos is all camelCased, and almost all D code uses Phobos, writing your own code with something else makes it doubly ugly. So nowadays I just use Phobos style for my own code. :-P  Nevertheless, I still dislike camelCase.
that's why i recommending camelCase. not because it's better, it's just happens. ;-)

yet i can't go that far to drop my egyptian brackets or use four spaces for indentation.

On Monday, 10 November 2014 at 19:37:06 UTC, H. S. Teoh via Digitalmars-d-learn wrote:
> I have to say that I *hate* camelCase... it looks really ugly. But what
> looks uglier is a mixture of camelCase and something else.

Ah, but here I disagree. I like to use different formatting for different levels of semantics. I prefer lower case for ADT structs and CamelCasedClassesToSignifyDomainSpecificity.

Basically distinguishing high level from low level. It makes sense to give more EMPHASIS to high level constructs.

(but camelCase in ADTs and generic libraries suck ;-)

On Mon, Nov 10, 2014 at 11:27:13PM +0200, ketmar via Digitalmars-d-learn wrote:
> On Mon, 10 Nov 2014 11:35:04 -0800
> "H. S. Teoh via Digitalmars-d-learn"
> <digitalmars-d-learn@puremagic.com> wrote:
> 
> > I have to say that I *hate* camelCase... it looks really ugly. But what looks uglier is a mixture of camelCase and something else. And since Phobos is all camelCased, and almost all D code uses Phobos, writing your own code with something else makes it doubly ugly. So nowadays I just use Phobos style for my own code. :-P  Nevertheless, I still dislike camelCase.
>
> that's why i recommending camelCase. not because it's better, it's just happens. ;-)

I'd rather use underscore_separated_words any day, than havingAllWordsSmushedTogetherIntoOverlyLongIdentifiers that makes my eyes bleed.

But mixing Phobos camelCase with underscored_identifiers makes my eyes bleed even more, so it's at least tolerable.


> yet i can't go that far to drop my egyptian brackets or use four spaces for indentation.

I used to be an Egyptian-braces / tabs-only-indentation advocate. That works reasonably well in C/C++, but I find that with idiomatic D, Phobos style actually works much better. (Well, except that horrid camelCasing, but hey, you can't win every battle.)  D code tends to require many more levels of indentation than C/C++, so using tabs can be quite cumbersome. also, Egyptian braces tend to work better when the leading line of nested blocks is simple, but in D, esp. with the complexity of function declarations, the opposite is true.

But at least none of us use the following bracing style, which I had the misfortune of coming across many years ago (I kid you not, people actually exist who write code like this):

	int my_func(int arg) {
		if (arg==1) {
			printf("One\n");
			}
		else {
			printf("Not one\n");
			}
		for (i=0; i<10; i++) {
			int x = i*2;
			do_something_else(x);
			}
		}

I think I needed therapy after encountering this. :-P


T

-- 
Let's eat some disquits while we format the biskettes.