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