www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Strictness of language styling

reply Etienne <etcimon gmail.com> writes:
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?
Nov 10 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Nov 10 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Nov 10 2014
next sibling parent Etienne <etcimon gmail.com> writes:
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
Nov 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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=20
 prefer the camelCase and it seems most D people do, but if you're=20
 translating another library, there's value it keeping it the same=20
 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.
Nov 10 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
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!
Nov 10 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 ;-)
Nov 10 2014
parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Mon, Nov 10, 2014 at 09:36:18PM +0000, via Digitalmars-d-learn wrote:

 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 ;-)


No idea what you're talking about, but I was referring to
squishingAllWordsIntoOneUnreadableMess vs.
keeping_them_visually_separate_and_readable.


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have biases. 
He/She has prejudices. -- Gene Wirchenko
Nov 10 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 10 November 2014 at 22:04:20 UTC, H. S. Teoh via 
Digitalmars-d-learn wrote:

 No idea what you're talking about, but I was referring to
 squishingAllWordsIntoOneUnreadableMess vs.
 keeping_them_visually_separate_and_readable.


I like the keeping_the_visually_separate_and_readable when it 
used for something generic that basically "extends" the language, 
but SquishingWordsTogether when is a classification related to 
the domain, e.g.:

database.for_all_valid_entities(somelambda);

string
list!nodetype

vs

class Car…
class RacingCar…
Nov 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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.
Nov 10 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
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.
Nov 10 2014
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/10/2014 02:00 PM, H. S. Teoh via Digitalmars-d-learn wrote:


 (I kid you not, people
 actually exist who write code like this):


I know one of those people! They are from a different era. :)


 	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);
 			}
 		}


Note especially how that last brace is there to get the unwary! :)


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


Same here! At least they used curly brackets for single-statements in 
the code above. In my case, they are truly optional. :(

(By the way, do you happen to know whether there are Emacs coding styles 
that help with that syntax? I could use one.)

Ali
Nov 10 2014
prev sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Mon, 10 Nov 2014 14:00:32 -0800
"H. S. Teoh via Digitalmars-d-learn"
<digitalmars-d-learn puremagic.com> wrote:


 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.


i HATE tabs. i hate tabs so much that all of my scripting languages
considers tab character as fatal syntax error.


 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):
=20
 	int my_func(int arg) {
 		if (arg=3D=3D1) {
 			printf("One\n");
 			}
 		else {
 			printf("Not one\n");
 			}
 		for (i=3D0; i<10; i++) {
 			int x =3D i*2;
 			do_something_else(x);
 			}
 		}
=20
 I think I needed therapy after encountering this. :-P


please, make me unsee that!
Nov 10 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Nov 10 2014