www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - renamepalooza time

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
The following symbols in std.string don't satisfy the Phobos naming 
conventions and need to be renamed:

LS PS capwords countchars entab expandtabs hexdigits icmp iswhite 
ljustify lowercase maketrans newline octdigits removechars rjustify 
sformat splitlines stripl stripr tolower tolowerInPlace toupper 
toupperInPlace tr whitespace zfill

Opinions on what to rename?


Thanks,

Andrei
Jan 20 2011
next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:


 The following symbols in std.string don't satisfy the Phobos naming
 conventions and need to be renamed:
 
 LS PS capwords countchars entab expandtabs hexdigits icmp iswhite
 ljustify lowercase maketrans newline octdigits removechars rjustify
 sformat splitlines stripl stripr tolower tolowerInPlace toupper
 toupperInPlace tr whitespace zfill
 
 Opinions on what to rename?
 
 
 Thanks,
 
 Andrei


Are there any conventions beyond what case to use?

I see this common pattern: verb-noun (expand-tabs) but for what I think is 
called adverbs in English it is a bit mixed (ljustify vs stripl).


These ones should be simply lower camel case:

capwords countchars entab expandtabs hexdigits octdigits removechars tolower 
tolowerInPlace toupper toupperInPlace lowercase maketrans splitlines


newline and whitespace: not sure how it is called in English, but these look 
like they have become single words and are fine.

LS and PS: since these are constants, upper case is ok, although LS is 
inconsistent with std.path.linesep. 

iswhite -> isWhitespace

tr: would say translate, but it's already there. Doesn't it overlap too 
much?

Then these remain, I'm less sure about them:

icmp ljustify rjustify sformat stripl stripr zfill

Possibly:

icmp: ok, it's a single abbreviation and insensitiveCompare is too much
ljustify -> leftJustify
rjustify -> rightJustify
sformat -> stringFormat (?)
stripl -> leftStrip
stripr -> rightStrip
zfill -> zeroFill (or better, ditch it and overload justify to take the 
filling char)
Jan 21 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 01/21/2011 09:43 AM, Lutger Blijdestijn wrote:

 newline and whitespace: not sure how it is called in English, but these look
 like they have become single words and are fine.


I would not make such exceptions because there is no rational criterion 
to determine which multiple-word terms have become kinds of single-word 
terms, in english, AFAIK (eg: filename, dirname, drivename, fullname, 
shortname?). Anyway, D is not an english dialect, it just reuses the 
english lexicon.
Programmers would be left in constant doubt. Thus, the only practical 
scheme is a systematic rule: more-than-one-word ==> camel-case. It's 
more annoying to type, agreed, for common 2-words-only terms; but one 
can then always guess what the correct form is --without any doubt.
Also: very newcomer friendly.

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/21/2011 09:43 AM, Lutger Blijdestijn wrote:

 LS and PS: since these are constants, upper case is ok, although LS is
 inconsistent with std.path.linesep.


Consistency across stdlib modules and with D builtin names (esp types) 
would be even more helpful than proper casing, imo.

[Also: Is there any chance to have a builtin name reform for Dn? This 
could be progressive: introduce builtin aliases --> deprecate 
non-conformant ones --> let conformant ones only.]

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
 ljustify ->  leftJustify
 rjustify ->  rightJustify
 stripl ->  leftStrip
 stripr ->  rightStrip


I suggest it should be rather justifyLeft/Right and stripLeft/Right. 
It's easier to read and it works better with code completion.
Jan 21 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 20 January 2011 23:57:39 Andrei Alexandrescu wrote:

 The following symbols in std.string don't satisfy the Phobos naming
 conventions and need to be renamed:
 
 LS PS capwords countchars entab expandtabs hexdigits icmp iswhite
 ljustify lowercase maketrans newline octdigits removechars rjustify
 sformat splitlines stripl stripr tolower tolowerInPlace toupper
 toupperInPlace tr whitespace zfill
 
 Opinions on what to rename?


LS = lineSep
PS = paragraphSep
capwords = capitalizeWords? capWords?
countchars = countChars

Well, entab, I'd argue _does_ follow the naming convention, because entab would 
be a verb, albeit a made up one. Certainly, en is a prefix, not another word,
so 
I think that entab is fine. If that doesn't fly, then go with enTab, I guess,
but 
I'd argue that entab is a single word and fine as it is.

expandtabs = expandTabs
hexdigits = hexDigits

icmp, I'd actually be tempted to just leave as-is, since it's simple and clear 
and goes well with cmp. But if that's not acceptable, I guess that I'd suggest 
cmpIgnoreCase. It is a tad verbose though. Or I suppose that you could just do 
iCmp.

iswhite = isWS, isWhitespace, or isWhite (I'd probably pick isWS)
ljustify = leftJustify
lowercase = lettersLC
maketrans = makeTransTable

I'd leave newline as is. newline is pretty much used as a single word like that 
in programming when talking about \n, so I'd consider it one word, and so it's 
fine as-is.

octdigits = octDigits
removechars = removeChars
rjustify = rightJustify

sformat = formatInPlace? I'm not sure that I quite get what this function does 
though.

splitlines = splitLines

stripl = stripLeft (though honestly, I kind of like stripl and stripr, and it's 
just dumb to capitalize the last letter)
stripr = stripRight

tolower = toLower
tolowerInPlace = toLowerInPlace
toupper = toUpper
toupperInPlace = toUpperInPlace

tr? The name means nothing to me. I haven't a clue where the name comes from,
so 
I can't really give a better version of the same name. As it is, tr seems fine
to 
me, particularly since tR just seems stupid. It should probably get a more 
descriptive name though. replaceChars?

Similar to newline, I'd consider whitespace to be one word and just fine as is. 
After all, you don't type new line or white space when talking about newlines
or 
whitespace.  newline and whitespace are both whole words with special meaning
in 
the world of programming.

zfill is just a weird name. It's slighty better than tr in that it does "fill"
in 
the string, but truth be told, without reading the source code, I don't know 
what it really does. I would _expect_ that the justify functions would move 
whatever space was around the string to the left, right, or both depending on 
which justify function you use, but I don't know. And how would that relate to 
filling in the string with 0's? Does it use 0 instead of spaces? The simplest 
would be to just rename it zFill, but unless zfill is a semi-standard/common
name 
from other languages or libraries, a more descriptive name might be preferable. 
I have no idea what that would be though.

- Jonathan M Davis
Jan 21 2011
parent reply Brad <brad.lanam.comp_nospam nospam_gmail.com> writes:
On 2011-01-21, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 tr? The name means nothing to me. I haven't a clue where the name comes from,
so
 I can't really give a better version of the same name. As it is, tr seems fine
to
 me, particularly since tR just seems stupid. It should probably get a more
 descriptive name though. replaceChars?


Just for everyone's info.

tr is a standard unix command; been around forever,
and it is a mnemonic for 'translate'.

It's also in perl.
Jan 23 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 23 January 2011 07:12:16 Brad wrote:

 On 2011-01-21, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 tr? The name means nothing to me. I haven't a clue where the name comes
 from, so I can't really give a better version of the same name. As it
 is, tr seems fine to me, particularly since tR just seems stupid. It
 should probably get a more descriptive name though. replaceChars?


 
 Just for everyone's info.
 
 tr is a standard unix command; been around forever,
 and it is a mnemonic for 'translate'.
 
 It's also in perl.
 


 field.


Good to know. I know a number of unix/linux commands, but there always seems to 
be more of them... Not that that's a bad thing.

- Jonathan M Davis
Jan 23 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 21 January 2011 00:44:26 Jonathan M Davis wrote:

 On Thursday 20 January 2011 23:57:39 Andrei Alexandrescu wrote:

 The following symbols in std.string don't satisfy the Phobos naming
 conventions and need to be renamed:
 
 LS PS capwords countchars entab expandtabs hexdigits icmp iswhite
 ljustify lowercase maketrans newline octdigits removechars rjustify
 sformat splitlines stripl stripr tolower tolowerInPlace toupper
 toupperInPlace tr whitespace zfill
 
 Opinions on what to rename?


 
 LS = lineSep
 PS = paragraphSep
 capwords = capitalizeWords? capWords?
 countchars = countChars
 
 Well, entab, I'd argue _does_ follow the naming convention, because entab
 would be a verb, albeit a made up one. Certainly, en is a prefix, not
 another word, so I think that entab is fine. If that doesn't fly, then go
 with enTab, I guess, but I'd argue that entab is a single word and fine as
 it is.
 
 expandtabs = expandTabs
 hexdigits = hexDigits
 
 icmp, I'd actually be tempted to just leave as-is, since it's simple and
 clear and goes well with cmp. But if that's not acceptable, I guess that
 I'd suggest cmpIgnoreCase. It is a tad verbose though. Or I suppose that
 you could just do iCmp.
 
 iswhite = isWS, isWhitespace, or isWhite (I'd probably pick isWS)
 ljustify = leftJustify
 lowercase = lettersLC
 maketrans = makeTransTable
 
 I'd leave newline as is. newline is pretty much used as a single word like
 that in programming when talking about \n, so I'd consider it one word,
 and so it's fine as-is.
 
 octdigits = octDigits
 removechars = removeChars
 rjustify = rightJustify
 
 sformat = formatInPlace? I'm not sure that I quite get what this function
 does though.
 
 splitlines = splitLines
 
 stripl = stripLeft (though honestly, I kind of like stripl and stripr, and
 it's just dumb to capitalize the last letter)
 stripr = stripRight
 
 tolower = toLower
 tolowerInPlace = toLowerInPlace
 toupper = toUpper
 toupperInPlace = toUpperInPlace
 
 tr? The name means nothing to me. I haven't a clue where the name comes
 from, so I can't really give a better version of the same name. As it is,
 tr seems fine to me, particularly since tR just seems stupid. It should
 probably get a more descriptive name though. replaceChars?
 
 Similar to newline, I'd consider whitespace to be one word and just fine as
 is. After all, you don't type new line or white space when talking about
 newlines or whitespace.  newline and whitespace are both whole words with
 special meaning in the world of programming.
 
 zfill is just a weird name. It's slighty better than tr in that it does
 "fill" in the string, but truth be told, without reading the source code,
 I don't know what it really does. I would _expect_ that the justify
 functions would move whatever space was around the string to the left,
 right, or both depending on which justify function you use, but I don't
 know. And how would that relate to filling in the string with 0's? Does it
 use 0 instead of spaces? The simplest would be to just rename it zFill,
 but unless zfill is a semi-standard/common name from other languages or
 libraries, a more descriptive name might be preferable. I have no idea
 what that would be though.
 
 - Jonathan M Davis


Also, I'd suggest that we not be OCD about our naming conventions. We should 
strive to stick to camel-casing function names with the first letter being 
lowercase, but if there's a function that just looks better not quite following 
the conventions, then we should go with that - particularly if camel-casing 
everything leads to really long names everywhere.

For instance, I have no problem with stripl. I think that it would be stupid to 
just make the last letter uppercase, and stripLeft is more verbose. The same 
goes for icmp. icmp fits really well with cmp, and pretty much anything which 
tries to camel-case it becomes excessively verbose.

So, I think that we should generally follow our naming conventions, but I don't 
think that we should absolutely require that they be followed _exactly_ all the 
time - just like sometimes it's better to format code somewhat differently from 
what a coding standard requires, because in a particular case, the result of 
following the standard would be much harder to read, even if following the 
standard _normally_ leads to more readable code.

- Jonathan M Davis
Jan 21 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Fri, 21 Jan 2011 01:57:39 -0600, Andrei Alexandrescu wrote:


 The following symbols in std.string don't satisfy the Phobos naming
 conventions and need to be renamed:
 
 LS PS capwords countchars entab expandtabs hexdigits icmp iswhite
 ljustify lowercase maketrans newline octdigits removechars rjustify
 sformat splitlines stripl stripr tolower tolowerInPlace toupper
 toupperInPlace tr whitespace zfill
 
 Opinions on what to rename?



I think the following are fine, because you would most likely write them 
as single words in ordinary text:

  entab, lowercase, newline, whitespace

These should simply be camelCased:

  countChars, expandTabs, hexDigits, removeChars, splitLines,
  toLower, toLowerInPlace, toUpper, toUpperInPlace

These should be expanded a bit and camelCased:

  LS:        lineSep, lineSeparator
  PS:        paragraphSep, paragraphSeparator
  capwords:  capitalizeWords
  iswhite:   isWhitespace
  ljustify:  leftJustify
  maketrans: makeTranslation
  octdigits: octalDigits
  rjustify:  rightJustify
  sformat:   formatString
  stripl:    stripLeft
  stripr:    stripRight
  zfill:     zeroFill

I don't know about icmp.  I guess I would prefer both cmp and icmp to be 
renamed to compare and compareCaseInsensitive.

I really have no idea what to call tr.

-Lars
Jan 21 2011
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Fri, 21 Jan 2011 09:05:24 +0000, Lars T. Kyllingstad wrote:


   sformat:   formatString


Forget that; I confused sformat() and format().  But maybe sformat should 
be renamed formatInPlace?  I dunno.

-Lars
Jan 21 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote:

 These should be expanded a bit and camelCased:

    LS:        lineSep, lineSeparator
    PS:        paragraphSep, paragraphSeparator


Isn't there a rule that constants all fully uppercase?

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 21, 2011 06:20:30 spir wrote:

 On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote:

 These should be expanded a bit and camelCased:
    LS:        lineSep, lineSeparator
    PS:        paragraphSep, paragraphSeparator


 
 Isn't there a rule that constants all fully uppercase?


That would be typical in C++ or Java, but that's not the case in D. Phobos 
certainly doesn't work that way in general, and Andrei doesn't want it to. The 
reasoning is that constants are so common in D (likely due to CTFE) that you'd 
have variables all over the place which were in all caps, and it would get 
really annoying. So, no. There is no rule in D that constants should be fully 
uppercase.

- Jonathan M Davis
Jan 21 2011
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Jonathan M Davis wrote:

 On Friday, January 21, 2011 06:20:30 spir wrote:

 On 01/21/2011 10:05 AM, Lars T. Kyllingstad wrote:

 These should be expanded a bit and camelCased:
    LS:        lineSep, lineSeparator
    PS:        paragraphSep, paragraphSeparator


 Isn't there a rule that constants all fully uppercase?


 That would be typical in C++


That is typical only for macros in C++.

I know that some shops use all capitals for constants, but not the 
standard library nor any of the places that I worked at. :)

Ali
Jan 21 2011
prev sibling parent reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Jonathan M Davis napisa=B3:


 These should be expanded a bit and camelCased:
    LS:        lineSep, lineSeparator
    PS:        paragraphSep, paragraphSeparator =20


=20
 Isn't there a rule that constants all fully uppercase? =20


=20
 That would be typical in C++ or Java, but that's not the case in D. Phobo=


s=20

 certainly doesn't work that way in general, and Andrei doesn't want it to=


. The=20

 reasoning is that constants are so common in D (likely due to CTFE) that =


you'd=20

 have variables all over the place which were in all caps, and it would ge=


t=20

 really annoying.


Right on.


 So, no. There is no rule in D that constants should be fully=20
 uppercase.


So if not uppercase, what is the convention for constants then? And, to hai=
r-split more, what is a constant to begin with? Would e.g. a big immutable =
configuration tree structure fall into that bucket? Or a logger object?

--=20
Tomek
Jan 21 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 21, 2011 13:46:11 Tomek Sowi=F1ski wrote:

 Jonathan M Davis napisa=B3:

 These should be expanded a bit and camelCased:
    LS:        lineSep, lineSeparator
    PS:        paragraphSep, paragraphSeparator


=20
 Isn't there a rule that constants all fully uppercase?


=20
 That would be typical in C++ or Java, but that's not the case in D.
 Phobos certainly doesn't work that way in general, and Andrei doesn't
 want it to. The reasoning is that constants are so common in D (likely
 due to CTFE) that you'd have variables all over the place which were in
 all caps, and it would get really annoying.


=20
 Right on.
=20

 So, no. There is no rule in D that constants should be fully
 uppercase.


=20
 So if not uppercase, what is the convention for constants then? And, to
 hair-split more, what is a constant to begin with? Would e.g. a big
 immutable configuration tree structure fall into that bucket? Or a logger
 object?


As far as Phobos goes, constants are named the same way that any other vari=
able=20
is. I don't think that there are any special naming conventions based on=20
variable type or constness or whatnot. It's all based on the type of symbol=
=2E=20
Typically, everything is camelcase, user-defined types start with a capital=
=20
letter, and everything else starts with a lowercase letter.

The most typical constants are enums, but there are cases where you can't d=
o=20
that, because CTFE isn't advanced enough yet (like with you configuration t=
ree=20
structure), in which case immutable is used along with static constructors.=
=20
Ideally though, they'd pretty much always be generated with CTFE and be enu=
ms.

Generally-speaking, when referring to constants, people are referring to=20
variables with a global lifetime which are set to an initial value and neve=
r=20
(and cannot ever) change once set.

=2D Jonathan M Davis
Jan 21 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/21/2011 10:46 PM, Tomek Sowiński wrote:

 So if not uppercase, what is the convention for constants then? And, to
hair-split more, what is a constant to begin with? Would e.g. a big immutable
configuration tree structure fall into that bucket? Or a logger object?


Very personal def: I give constant & variable about the same meaning as 
in math: something predefined, or conversely undefined, at design time 
(which implies in a compiled language also at compile-time).
	f : x --> k.x
k is a constant, x a variable. Same below:
	factor3 = 3;
	int triple (int x) {return factor3 * x;}
Thus, I consider "enum" and "static" (in some of its numerous senses) as 
constant qualifiers.

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-21 08:57, Andrei Alexandrescu wrote:

 The following symbols in std.string don't satisfy the Phobos naming
 conventions and need to be renamed:

 LS PS capwords countchars entab expandtabs hexdigits icmp iswhite
 ljustify lowercase maketrans newline octdigits removechars rjustify
 sformat splitlines stripl stripr tolower tolowerInPlace toupper
 toupperInPlace tr whitespace zfill

 Opinions on what to rename?


 Thanks,

 Andrei


LS -> lineSeparator/LineSeparator
PS -> paragraphSeparator/ParagraphSeparator
capwords -> capitalizeWords/capitalizeAll // should this function really 
mess with whitespaces ?

countchars -> countChars/count
entab -> entab/spacesToTabs
expandtabs -> expandTabs/tabsToSpaces
hexdigits -> hexDigits
icmp -> insensitiveCompare
iswhite -> isWhitespace
ljustify -> leftJustify /justifyLeft
lowercase -> lowercaseChars
maketrans -> makeTranslationTable // is this really needed, can't 
translate to this

newline -> newline
octdigits -> octalDigits
removechars -> removeChars/remove
rjustify -> rightJustify/justifyRight
sformat -> formatInPlace
splitlines -> splitLines
stripl -> stripLeft
stripr -> striptRight
tolower -> toLower/toLowercase/toLowerCase
tolowerInPlace ->  toLowerInPlace/toLowercaseInPlace/toLowerCaseInPlace
toupper -> toUpper/toUppercase/toUpperCase
toupperInPlace -> toUpperInPlace/toUppercaseInPlace/toUpperCaseInPlace
tr -> replaceWithmModifiers
whitespace -> whitespaceCharsr
zfill -> zeroFill

-- 
/Jacob Carlborg
Jan 21 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 01/21/2011 10:14 AM, Jacob Carlborg wrote:

 ljustify -> leftJustify /justifyLeft
 rjustify -> rightJustify/justifyRight
 stripl -> stripLeft
 stripr -> striptRight


Consistency. Eg: all qualifiers come first (like in english).

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 21, 2011 06:16:16 spir wrote:

 On 01/21/2011 10:14 AM, Jacob Carlborg wrote:

 ljustify -> leftJustify /justifyLeft
 rjustify -> rightJustify/justifyRight
 stripl -> stripLeft
 stripr -> striptRight


 
 Consistency. Eg: all qualifiers come first (like in english).


Actually, it's a bit funny in this case. You're stripping the left of the
string 
or the right of the string, so stripLeft and stripRight make  a lot more sense 
than leftStrip and rightStrip (actually, those would be pretty horrible IMO). 
However, when talking about justifying text, you typically talk about it being 
left-justified or right-justified (or centered). So, it's more natural to have 
leftJustify and rightJustify. Now, it might technically be more correct to talk 
about justifying it to the right or left, but no one really talks that way. I 
believe that left justify and right justify are typically used as if they were 
composite verbs rather than talking about justifying text to the right or left.

So, it's going to make more sense to most people to have stripLeft, stripRight, 
leftJustify, and rightJustify rather than trying to put right and left on the 
same side for both strip and justify.

- Jonathan M Davis
Jan 21 2011
prev sibling next sibling parent foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:


 The following symbols in std.string don't satisfy the Phobos naming 
 conventions and need to be renamed:
 
 LS PS capwords countchars entab expandtabs hexdigits icmp iswhite 
 ljustify lowercase maketrans newline octdigits removechars rjustify 
 sformat splitlines stripl stripr tolower tolowerInPlace toupper 
 toupperInPlace tr whitespace zfill
 
 Opinions on what to rename?
 
 
 Thanks,
 
 Andrei


A few notes:
A) As discussed already in the thread about Unicode, some string algorithms
depend on locale/language. From what I see in the docs this isn't handled
properly at the moment. Is it possible to remove/deprecate the functions or at
least add a warning in the docs? 
I prefer them to be marked as deprecated rather than renamed since they
hopefully will be replaced anyway in the future. 
B) I prefer trim over strip as it is more descriptive IMO:
stripl => leftTrim
stripr => rightTrim

strip sounds to me like something related to clothing.
Jan 21 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/21/2011 09:44 AM, Jonathan M Davis wrote:

 Well, entab, I'd argue_does_  follow the naming convention, because entab would
 be a verb, albeit a made up one. Certainly, en is a prefix, not another word,
so
 I think that entab is fine. If that doesn't fly, then go with enTab, I guess,
but
 I'd argue that entab is a single word and fine as it is.


I fully agree with you on the linguistic side: "entab" is a single-word 
term, just like eg "input" (no-one would suggest "inPut" ;-). But 
practically, the decomposition "enTab" helps understanding this 
identifier by nicely highlighting "tab", don't you think?
This is even more relevant for foreigners, who have here to guess: (1) 
that "entab" is not a 'normal' english single-word term they would just 
not know (2) as you say, that en- is a verb-forming prefix in english 
one can more or less freely use. Non-trivial.

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 21, 2011 06:04:53 spir wrote:

 On 01/21/2011 09:44 AM, Jonathan M Davis wrote:

 Well, entab, I'd argue_does_  follow the naming convention, because entab
 would be a verb, albeit a made up one. Certainly, en is a prefix, not
 another word, so I think that entab is fine. If that doesn't fly, then
 go with enTab, I guess, but I'd argue that entab is a single word and
 fine as it is.


 
 I fully agree with you on the linguistic side: "entab" is a single-word
 term, just like eg "input" (no-one would suggest "inPut" ;-). But
 practically, the decomposition "enTab" helps understanding this
 identifier by nicely highlighting "tab", don't you think?
 This is even more relevant for foreigners, who have here to guess: (1)
 that "entab" is not a 'normal' english single-word term they would just
 not know (2) as you say, that en- is a verb-forming prefix in english
 one can more or less freely use. Non-trivial.


I'm afraid that I don't agree at all. enTab is hideous and arguably confusing 
precisely because en is _not_ a word. I'd start trying to figure out what en
was 
short for if I saw an enTab function. entab is _far_ clearer. Would you make a 
function named enClose? I should hope not. Granted, enclose is actually a word 
that you'll find in a dictionary, but en is a normal prefix in English, and
trying 
to treat it as a word or abbrevation in function names would just be confusing.

- Jonathan M Davis
Jan 21 2011
parent Don <nospam nospam.com> writes:
Jonathan M Davis wrote:

 On Friday, January 21, 2011 06:04:53 spir wrote:

 On 01/21/2011 09:44 AM, Jonathan M Davis wrote:

 Well, entab, I'd argue_does_  follow the naming convention, because entab
 would be a verb, albeit a made up one. Certainly, en is a prefix, not
 another word, so I think that entab is fine. If that doesn't fly, then
 go with enTab, I guess, but I'd argue that entab is a single word and
 fine as it is.


 I fully agree with you on the linguistic side: "entab" is a single-word
 term, just like eg "input" (no-one would suggest "inPut" ;-). But
 practically, the decomposition "enTab" helps understanding this
 identifier by nicely highlighting "tab", don't you think?
 This is even more relevant for foreigners, who have here to guess: (1)
 that "entab" is not a 'normal' english single-word term they would just
 not know (2) as you say, that en- is a verb-forming prefix in english
 one can more or less freely use. Non-trivial.


 
 I'm afraid that I don't agree at all. enTab is hideous and arguably confusing 
 precisely because en is _not_ a word. I'd start trying to figure out what en
was 
 short for if I saw an enTab function. entab is _far_ clearer. Would you make a 
 function named enClose? I should hope not. Granted, enclose is actually a word 
 that you'll find in a dictionary, but en is a normal prefix in English, and
trying 
 to treat it as a word or abbrevation in function names would just be confusing.
 
 - Jonathan M Davis


Even worse -- 'en' _is_ a word! (From typography, with 'en' and 'em'). 
It could mean a narrow tab, in contrast to an emTab, which would be a 
wide tab...

It's unfortunate that the dominant language for programming is the one 
with by far the worst spelling.
Jan 22 2011
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Andrei Alexandrescu wrote:


 iswhite


I like separating is with an underscore, like most coding styles do:

   is_whitespace

Warm and fuzzy... :)

Ali
Jan 21 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 21, 2011 13:30:11 Ali =C3=87ehreli wrote:

 Andrei Alexandrescu wrote:
  > iswhite
=20
 I like separating is with an underscore, like most coding styles do:
=20
    is_whitespace
=20
 Warm and fuzzy... :)


Most? I've never dealt with a coding style that had underscores. It's gener=
ally=20
camelcase, though I get the impression that using underscores in C code is =
more=20
common (I've mostly used C++ and Java). Regardless however, Phobos' coding =
style=20
uses camelcase, not underscores. And this whole thread was started to try a=
nd=20
find better names for functions which need new names, because they don't=20
currently follow Phobos' naming conventions.

=2D Jonathan M Davis
Jan 21 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 Most? I've never dealt with a coding style that had underscores. It's
generally 
 camelcase, though I get the impression that using underscores in C code is
more 
 common (I've mostly used C++ and Java). Regardless however, Phobos' coding
style 
 uses camelcase, not underscores.


You are right. But I'd like to know why Phobos uses camelcase instead of
underscores (as used in C and Python). I think variable names in camelcase are
less noisy.

Bye,
bearophile
Jan 21 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 01/22/2011 12:17 AM, bearophile wrote:

 You are right. But I'd like to know why Phobos uses camelcase instead 


of underscores (as used in C and Python). I think variable names in 
camelcase are less noisy.

I have used underscores for a long time, then had to switch to camelcase 
for conformance with an enforced coding style. Annoyed for a while. 
Then, I realised that camelcase may be better because it is visually 
clearer in complicated expressions; I mean '_' is too "shy", it doesn't 
obviously enough tie together parts of a single identifier.
Even '-' (heavily used in languages that allow it) is too "shy".
I also don't like '_' at start/end of ids for similar reasons.
	xyz.foo_._bar (param);
(But it's only me...)

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
 I think variable names in camelcase are less noisy.


Sorry, I meant:

 I think variable names in camelcase are more noisy.


Bye,
bearophile
Jan 21 2011
parent Justin Johansson <jj nospam.com> writes:
On 22/01/11 10:55, bearophile wrote:

 I think variable names in camelcase are less noisy.


 Sorry, I meant:

 I think variable names in camelcase are more noisy.


 Bye,
 bearophile



I think youAre probablyRight (that camelCase is moreNoisy) but 
unfortunately yourArgument foundered beCause of a typoMistake.

:-) Justin
Jan 22 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 21, 2011 15:17:00 bearophile wrote:

 Jonathan M Davis:

 Most? I've never dealt with a coding style that had underscores. It's
 generally camelcase, though I get the impression that using underscores
 in C code is more common (I've mostly used C++ and Java). Regardless
 however, Phobos' coding style uses camelcase, not underscores.


 
 You are right. But I'd like to know why Phobos uses camelcase instead of
 underscores (as used in C and Python). I think variable names in camelcase
 are less noisy.


Probably because Walter and/or other folks working on it early on preferred 
camelcase. I'm welling to bet that a fair number of the current Phobos devs are 
the same (though apparently, Andrei isn't, given one of his posts in this 
thread). I expect that Phobos uses camelcase simply because that's what enough 
of the Phobos developers (particularly early developers) were used to.

Personally, camelcase vs underscores isn't even something that I normally think 
about. I just always use camelcase. On _rare_ occasion, I might use underscores 
because it seems to fit a particular situation, but that's _really_ rare. The 
only time that I normally stick underscores in variable names is to indicate 
private member variables. But I find using underscores in names to generally be 
ugly and noisy. I expect that a lot of that just comes down to what you're used 
to though.

- Jonathan M Davis
Jan 21 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.804.1295659471.4748.digitalmars-d puremagic.com...

 Personally, camelcase vs underscores isn't even something that I normally 
 think
 about. I just always use camelcase. On _rare_ occasion, I might use 
 underscores
 because it seems to fit a particular situation, but that's _really_ rare. 
 The
 only time that I normally stick underscores in variable names is to 
 indicate
 private member variables. But I find using underscores in names to 
 generally be
 ugly and noisy. I expect that a lot of that just comes down to what you're 
 used
 to though.


I'm the same way. Plus, I find it really awkward to constantly type a bunch 
of underscores. It feels less like "typing" and more like "finger 
acobatics."
Jan 22 2011
parent reply so <so so.do> writes:
 I'm the same way. Plus, I find it really awkward to constantly type a  
 bunch
 of underscores. It feels less like "typing" and more like "finger
 acobatics."


It is worse for camelCase, at least you can bind "_" to another key.
Only one thing i like about camelCase is that, it takes less space.
Jan 22 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"so" <so so.do> wrote in message news:op.vpqi7ngy7dtt59 so-pc...

 I'm the same way. Plus, I find it really awkward to constantly type a 
 bunch
 of underscores. It feels less like "typing" and more like "finger
 acobatics."


 It is worse for camelCase,


Don't see how. "iT" vs "i_t":

iT:
[i] [hold shift] [t] [release shift]

i_t:
[i] [hold shift] [reach over to -] [release shift] [t]


 at least you can bind "_" to another key.


I already use all my other keys.
Jan 22 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
That's why they invented the concept of rebinding the keys. And why
Vim is a modal editor. Etc etc etc..
Jan 22 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/23/2011 02:39 AM, Nick Sabalausky wrote:

 "so"<so so.do>  wrote in message news:op.vpqi7ngy7dtt59 so-pc...

 I'm the same way. Plus, I find it really awkward to constantly type a
 bunch
 of underscores. It feels less like "typing" and more like "finger
 acobatics."


 It is worse for camelCase,


 Don't see how. "iT" vs "i_t":

 iT:
 [i] [hold shift] [t] [release shift]

 i_t:
 [i] [hold shift] [reach over to -] [release shift] [t]


Depends on your keyboard, Nick: '_' does not require shift, on mine 
(don't ask why). But '[' & ']' require AltGr :-( Think they are directly 
accessible on US keyboards, aren't they? This would explain they massive 
use in PLs.

denis
_________________
vita es estrany
spir.wikidot.com
Jan 22 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/11 4:49 PM, Jonathan M Davis wrote:

 On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote:

 Andrei Alexandrescu wrote:
   >  iswhite

 I like separating is with an underscore, like most coding styles do:

     is_whitespace

 Warm and fuzzy... :)


 Most? I've never dealt with a coding style that had underscores. It's generally
 camelcase, though I get the impression that using underscores in C code is more
 common (I've mostly used C++ and Java). Regardless however, Phobos' coding
style
 uses camelcase, not underscores. And this whole thread was started to try and
 find better names for functions which need new names, because they don't
 currently follow Phobos' naming conventions.


Ever since I worked with STL, I fell in love with 
names_with_underscores. I can't explain it, but my feeling is that code 
using that convention is calm and levelheaded. Camel case forces me to 
think of one-word names because at the second word some beauty is 
already lost; never felt the same with the underscores. If I could go 
back in time I'd propose that convention throughout.

Andrei
Jan 21 2011
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:

 
 Ever since I worked with STL, I fell in love with 
 names_with_underscores. I can't explain it, but my feeling is that code 
 using that convention is calm and levelheaded. Camel case forces me to 
 think of one-word names because at the second word some beauty is 
 already lost; never felt the same with the underscores. 


I like the look of the STL convention, but overall prefer that Camel case
distinguishes between types and values.  It completely eliminates the need for
a "_type" suffix in STL-style typedefs, for one.
Jan 21 2011
parent torhu <no spam.invalid> writes:
On 22.01.2011 01:36, Sean Kelly wrote:

 Andrei Alexandrescu Wrote:

  Ever since I worked with STL, I fell in love with
  names_with_underscores. I can't explain it, but my feeling is that code
  using that convention is calm and levelheaded. Camel case forces me to
  think of one-word names because at the second word some beauty is
  already lost; never felt the same with the underscores.


 I like the look of the STL convention, but overall prefer that Camel case
distinguishes between types and values.  It completely eliminates the need for
a "_type" suffix in STL-style typedefs, for one.


No problem:

Some_type
some_variable

I haven't actually used this style personally.  I've just noticed that 
it's the style used throughout Stroustrup's latest book (Programming). 
Seems like the obvious next step for the underscore style of naming.
Jan 22 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/22/2011 01:16 AM, Andrei Alexandrescu wrote:

 Ever since I worked with STL, I fell in love with
 names_with_underscores. I can't explain it, but my feeling is that code
 using that convention is calm and levelheaded. Camel case forces me to
 think of one-word names because at the second word some beauty is
 already lost; never felt the same with the underscores. If I could go
 back in time I'd propose that convention throughout.


Nice, & surprising! I do not share your feeling (not at all), but I like 
very much the way you express it; and the weirdness to associate such a 
feeling with something_like_underscored_ids.


 Andrei


Denis
_________________
vita es estrany
spir.wikidot.com
Jan 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well, the underscored names might be easier to read since the words
are spaced apart. They might be easier to type as well, if you set a
hotkey for _. With camelcase you either have autocomplete to help you
or you have to use Shift all the time (you need shift for _ as well
unless you set a hotkey for it).
Jan 21 2011
prev sibling next sibling parent so <so so.do> writes:
 Ever since I worked with STL, I fell in love with  
 names_with_underscores. I can't explain it, but my feeling is that code  
 using that convention is calm and levelheaded. Camel case forces me to  
 think of one-word names because at the second word some beauty is  
 already lost; never felt the same with the underscores. If I could go  
 back in time I'd propose that convention throughout.


Agree on every bit!
Silly me, i was thinking you are one of those (or the one) that enforce  
camelCase!
Jan 22 2011
prev sibling next sibling parent piotrek <starpit tlen.pl> writes:
On Fri, 21 Jan 2011 18:16:20 -0600, Andrei Alexandrescu wrote:

 
 Ever since I worked with STL, I fell in love with
 names_with_underscores. I can't explain it, but my feeling is that code
 using that convention is calm and levelheaded. Camel case forces me to
 think of one-word names because at the second word some beauty is
 already lost; never felt the same with the underscores. If I could go
 back in time I'd propose that convention throughout.
 
 Andrei


Hehe. This the one only case I'm happy we can't turn back the time ;) For me 
camelCase is *much* more beautiful  than underscores. When reading STL 
code my eyes coupled with brain  have  difficulties with instant distinction 
where the name exactly  starts and ends (thanks to intention of simulating 
spaces). 

PS. One worders are the best, of course.

Cheers
Piotrek
Jan 22 2011
prev sibling next sibling parent Max Samukha <maxsamukha spambox.com> writes:
On 01/22/2011 02:16 AM, Andrei Alexandrescu wrote:

 On 1/21/11 4:49 PM, Jonathan M Davis wrote:

 On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote:

 Andrei Alexandrescu wrote:

 iswhite


 I like separating is with an underscore, like most coding styles do:

 is_whitespace

 Warm and fuzzy... :)


 Most? I've never dealt with a coding style that had underscores. It's
 generally
 camelcase, though I get the impression that using underscores in C
 code is more
 common (I've mostly used C++ and Java). Regardless however, Phobos'
 coding style
 uses camelcase, not underscores. And this whole thread was started to
 try and
 find better names for functions which need new names, because they don't
 currently follow Phobos' naming conventions.


 Ever since I worked with STL, I fell in love with
 names_with_underscores. I can't explain it, but my feeling is that code
 using that convention is calm and levelheaded. Camel case forces me to
 think of one-word names because at the second word some beauty is
 already lost; never felt the same with the underscores. If I could go
 back in time I'd propose that convention throughout.

 Andrei


My problem with underscore-delimited identifiers is that they can get 
really hard on eyes:

int my_temp_var = some_object_instance.some_field.some_other_field;

The dots are completely lost. Also, when identifiers are getting long 
(and in large libraries they tend to) the underscores become to look 
pretty annoying. I have worked with many conventions and camelCase 
remains my favorite for now.
Jan 22 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 22/01/2011 00:16, Andrei Alexandrescu wrote:

 Ever since I worked with STL, I fell in love with
 names_with_underscores. I can't explain it, but my feeling is that code
 using that convention is calm and levelheaded.


The explanation for that could very well be some form of Pavlovian 
reinforcement/conditioning. :)

-- 
Bruno Medeiros - Software Engineer
Feb 04 2011
parent Mafi <mafi example.org> writes:
Am 04.02.2011 15:11, schrieb Bruno Medeiros:

 On 22/01/2011 00:16, Andrei Alexandrescu wrote:

 Ever since I worked with STL, I fell in love with
 names_with_underscores. I can't explain it, but my feeling is that code
 using that convention is calm and levelheaded.


 The explanation for that could very well be some form of Pavlovian
 reinforcement/conditioning. :)


I would say it's the Stockholm syndrom :)

Mafi
Feb 04 2011
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Jonathan M Davis wrote:

 On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote:

 Andrei Alexandrescu wrote:
  > iswhite

 I like separating is with an underscore, like most coding styles do:

    is_whitespace

 Warm and fuzzy... :)


 
 Most? I've never dealt with a coding style that had underscores.


Sorry for being unclear. My comment was only in the context of is_. I 
like separating "is" with an underscore. Probably because "is" is not 
part of the name. It operates at a different linguistic level.


 It's generally
 camelcase, though I get the impression that using underscores in C code is
more 
 common (I've mostly used C++ and Java).


Same here: always camelcase, except in our C libraries. Now I like 
underscore more than before. :)


 Regardless however, Phobos' coding style
 uses camelcase, not underscores. And this whole thread was started to try and 
 find better names for functions which need new names, because they don't 
 currently follow Phobos' naming conventions.


I am aware of that. Then half seriously, let's change the standard to 
use underscore after "is". Also when parts of a camelcased name are too 
loosely related.

For example, when NodeReader is an interface and when we already have a 
LovelyDb, we may have a class named LovelyDb_NodeReader.

Ali
Jan 22 2011
parent reply spir <denis.spir gmail.com> writes:
On 01/23/2011 12:03 AM, Ali Çehreli wrote:

 Jonathan M Davis wrote:

 On Friday, January 21, 2011 13:30:11 Ali Çehreli wrote:

 Andrei Alexandrescu wrote:

 iswhite


 I like separating is with an underscore, like most coding styles do:

 is_whitespace

 Warm and fuzzy... :)


 Most? I've never dealt with a coding style that had underscores.


 Sorry for being unclear. My comment was only in the context of is_. I
 like separating "is" with an underscore. Probably because "is" is not
 part of the name. It operates at a different linguistic level.

  > It's generally

 camelcase, though I get the impression that using underscores in C
 code is more common (I've mostly used C++ and Java).


 Same here: always camelcase, except in our C libraries. Now I like
 underscore more than before. :)

  > Regardless however, Phobos' coding style

 uses camelcase, not underscores. And this whole thread was started to
 try and find better names for functions which need new names, because
 they don't currently follow Phobos' naming conventions.


 I am aware of that. Then half seriously, let's change the standard to
 use underscore after "is". Also when parts of a camelcased name are too
 loosely related.

 For example, when NodeReader is an interface and when we already have a
 LovelyDb, we may have a class named LovelyDb_NodeReader.

 Ali


Nice & sensible way of mixing both conventions :-) Sounds similar to 
using whitespace for visual grouping like in
	a*b + c*d
or
	[ [1,2,3] , [4,5,6] ]

But may be a bit too complicated for a public, free-willing, style, 
don't you think? Rather for an enforced project or corporate one, I'd say...

Denis
_________________
vita es estrany
spir.wikidot.com
Jan 22 2011
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
spir wrote:

 On 01/23/2011 12:03 AM, Ali Çehreli wrote:



 Sounds similar to
 using whitespace for visual grouping like in
     a*b + c*d
 or
     [ [1,2,3] , [4,5,6] ]

 But may be a bit too complicated for a public, free-willing, style,
 don't you think? Rather for an enforced project or corporate one, I'd
 say...


Agreed, but I will keep using an underscore after "is". Another reason 
why I do so is, when used with camelcase, that little "is" capitalizes 
the next word just to be consistent with the camelcase part of the 
naming conventions. When we have an attribute of an object named 
'ready', 'isReady()' doesn't match because 'ready' doesn't match 
'Ready'. An underscore makes it stay lowercased:

     is_ready();

The attribute can follow the camelcase rule and be consistent with the 
rest of the names:

     is_lastItem();

Ali
Jan 23 2011
parent spir <denis.spir gmail.com> writes:
On 01/23/2011 09:13 AM, Ali Çehreli wrote:

 Agreed, but I will keep using an underscore after "is". Another reason why I do
 so is, when used with camelcase, that little "is" capitalizes the next word
 just to be consistent with the camelcase part of the naming conventions. When
 we have an attribute of an object named 'ready', 'isReady()' doesn't match
 because 'ready' doesn't match 'Ready'. An underscore makes it stay lowercased:

      is_ready();

 The attribute can follow the camelcase rule and be consistent with the rest of
 the names:

      is_lastItem();


You're right, it's a nice convention.
Deins
-- 
_________________
vita es estrany
spir.wikidot.com
Jan 23 2011
prev sibling parent Paul D. Anderson <paul.removethis.d.anderson comcast.andthis.net> writes:
My two cents.

(Incidentally, when I learned to type -- in the USA in 1970 -- a "cents" symbol
was standard on the keyboard. Shift-2 or Shift-6, I think.)

Jacob Carlborg Wrote:


 
 LS -> lineSeparator/LineSeparator
 PS -> paragraphSeparator/ParagraphSeparator


These are established acronyms:
(http://www.unicode.org/standard/reports/tr13/tr13-5.html). I would leave them
as is.


 
 entab -> entab/spacesToTabs
 expandtabs -> expandTabs/tabsToSpaces


I prefer the more explicit "spacesToTabs" variants. I would have to double
check to see what "entab" means.


 ljustify -> leftJustify /justifyLeft


left/rightJustify is better, IMHO.


 lowercase -> lowercaseChars


"lowercase" is fine as is.


 newline -> newline


Mild preference for "newLine", but either would be fine.


 stripl -> stripLeft
 stripr -> striptRight


Yes, even though differs from left/rightJustify usage.


 tolower -> toLower/toLowercase/toLowerCase
 tolowerInPlace ->  toLowerInPlace/toLowercaseInPlace/toLowerCaseInPlace


toLower and toLowerInPlace


 toupper -> toUpper/toUppercase/toUpperCase
 toupperInPlace -> toUpperInPlace/toUppercaseInPlace/toUpperCaseInPlace


Ditto: toUpper and toUpperInPlace


 whitespace -> whitespaceCharsr


"whitespace" is fine as is.


 -- 
 /Jacob Carlborg
Jan 22 2011